On Mar 9, 2009, at 10:28 AM, Michaelian Ennis wrote:
I am confused as to why one would return eventNotHandledErr after
handling the event?
Because it's not really handling the event. It just happens to be
the only hook available for monitoring the application event loop
(in this case: the da
2009/3/9 erik quanstrom :
> i leave it as an exercize to the reader to port
> this to 9vx. ☺
>
There you are. Easy exercises are also good from time to time :)
The patch also allows to use Shift+Button3 as Button2 (as documented
in the man page).
Regards,
--
- yiyus || JGL .
diff -r a18e987216
On Sun, Mar 8, 2009 at 6:33 PM, Jeff Sickel wrote:
> All this chatter about blending and Russ' recent updates to p9p encouraged
> me to finally fix a small thing that's annoyed me with devdraw's on OS X:
> that odd blank (all white) window when waking a machine from sleep, exiting
> a screen saver
i submitted a patch to plan 9 with russ' fix:
memdraw32bit. thanks russ, andrey!
note: you will need to recompile your kernel,
not just applications that use libmemdraw.
i leave it as an exercize to the reader to port
this to 9vx. ☺
- erik
All this chatter about blending and Russ' recent updates to p9p
encouraged me to finally fix a small thing that's annoyed me with
devdraw's on OS X: that odd blank (all white) window when waking a
machine from sleep, exiting a screen saver, or un-hiding a devdraw
based application.
Here's
> Bug #3: MUL0123 is enabled whenever the src
> and dst both have 32-bit pixel width, but there is
> no check that the sub-channels are in the same
> order. You don't say what the image chans were
> in your test, but this:
>
> src rFF g00 b00 αFF
> mask kFF αFF
> dst r00 g00 b00 αFF
> dst after
Thanks for tracking this down and pointing out where
the error is. There are actually a handful of errors
in that code.
Assume a source value sv, source alpha sa,
mask alpha ma, destination value dv, and
destination alpha da. The values sv and dv
are stored premultiplied by their corresponding
a
ok, i think i am close, but i can go no further. here's what i did:
- view all images through ppm instead of png. what that means is that
i can do toppm $i > $i.ppm in 9vx and then see them on the hosting
Linux. since ppm is rather simple (doesn't do any draw ops but just
dumps the bytes) it is go
xgbr32 over xgbr32 or xrgb32 looks fine.
but xgbr32 over agbr32, for example,
results in a fade-to-blue and an extremely
slow display time. seems like the channels
are getting mixed up.
oddly, xrgb32 over argb32 works (but slowly).
- erik
just for fun, the attached file should run the whole gamut of
allocimage chan options in the 32-bit range (with RGB24 thrown in for
good measure) and will create files in /tmp for each possible
combination without involving drawing to the screen display (ideally
this should be done in memdraw, i su
in the case of 9vx running on Linux it's x8r8g8b8, drawterm on osx is
also x8r8g8b8.
here's how it breaks down drawing to display:
sourcedestination error
XRGB32 XRGB32 no
XBGR32 XRGB32 no
ARGB32 XRGB32 yes (see atta
On Wed Mar 4 18:42:46 EST 2009, fors...@terzarima.net wrote:
> >from 32-bit image to a 32-bit display.
>
> a 32-bit display? what's the result of cat /dev/draw/new?
1: !cat /dev/draw/new
9 0x8r8g8b8 0 0 0
16001200 0
>from 32-bit image to a 32-bit display.
a 32-bit display? what's the result of cat /dev/draw/new?
On Thu, Mar 5, 2009 at 10:31 AM, maht wrote:
> I decided to try some draw(2) exploration and I'm not getting what I
> expected from alpha blending.
>
> If I apply alpha to RGB24 images they change as expected but if I use RGBA32
> images and try to apply alpha it's going weird on me (or I am weird
> however it won't fix the program that you originally
> sent.
the "fix" (if you can call sidestepping the problem :a fix") for the
original program is to use RGB24 as the channel for black's
allocimage():
black = allocimage(display, Rect(0, 0, Dx(screen->r),
Dy(screen->r)), RGB24, 0, DBla
On Wed Mar 4 17:48:12 EST 2009, mirtchov...@gmail.com wrote:
> Erik, I think you're running in 32bpp mode, right?
yes. iirc my nvidia card was not willing to do 24bpp.
> To have 'png' render RGB24.png correctly make the following change to
> /sys/src/cmd/jpg/png.c:
however it won't fix the pro
Erik, I think you're running in 32bpp mode, right?
To have 'png' render RGB24.png correctly make the following change to
/sys/src/cmd/jpg/png.c:
% yesterday -d png.c
diff /n/dump/2009/0304/sys/src/cmd/jpg/png.c /sys/src/cmd/jpg/png.c
139c139
< Image *i, *i2;
---
> Image *i, *i2, *i3;
ok, those all exhibit the incorrect blending behaviour, would you not agree?
here's a .jpg that shows the correct behaviour and that should render
properly on Plan9. I just tried RGB24.png and it indeed renders
incorrectly in 9vx the way you're describing it. the jpg should be the
benchmark for co
2009/3/4 erik quanstrom :
> okay. i've corrected my misfire on the picture. i've included
> α.gif gif encoding of the screen from plan 9 native on the 386
> α.png png "
> αpic.jpg a picture taken of the screen.
This is wrong -- the idea is that you have a single white bar all the
way
the jpg file you attached doesn't look like a jpg file :(
On Wed, Mar 4, 2009 at 2:53 PM, erik quanstrom wrote:
> this is a picture of what this looks like on my screen.
> your attached png is 4 stripes of
> white->blue
> blue->blue
> magenta->blue
> cyan->blue
>
> - erik
this is a picture of what this looks like on my screen.
your attached png is 4 stripes of
white->blue
blue->blue
magenta->blue
cyan->blue
- erik<>
are you saying that you see the correct image but wee see the png
differently? can you convert it to gif instead of png?
On Wed, Mar 4, 2009 at 2:44 PM, erik quanstrom wrote:
> i didn't do a hex dump. it must be displayed differently
> outside of plan 9.
>
> - erik
>
>
i didn't do a hex dump. it must be displayed differently
outside of plan 9.
- erik
to see how it should look when drawn correctly use "type = ARGB32" and
RGB24 for black's allocimage(). see attached.
the alpha blending still works because when downgrading from
ARGB32->RGB24 (for drawing onto "black") the library still takes the
source color from black without issues. the bugs ap
but it doesn't: the red is drawn as blue, the green switches to pink
in the middle, and blue is drawn as red and cyan...
only the white is alpha-blended correctly.
On Wed, Mar 4, 2009 at 2:32 PM, erik quanstrom wrote:
> it looks fine on a native plan 9 386 terminal.
>
> - erik
it looks fine on a native plan 9 386 terminal.
- erik<>
that's quite interesting, and i suspect you've discovered a bug.
actually two bugs, maybe. one has to deal with drawing alpha-blended
images, the other with drawing using RGBA32...
the simplest way to trigger the second bug, which may or may not be
related to the first, is to draw using black, RGB
Hi,
I decided to try some draw(2) exploration and I'm not getting what I
expected from alpha blending.
If I apply alpha to RGB24 images they change as expected but if I use
RGBA32 images and try to apply alpha it's going weird on me (or I am
weird on it).
If I apply setalpha(DRed, 0x7F) an
28 matches
Mail list logo
