nanogui: Images not drawn (FLTK+nxlib app with nano-X)
Subject:
Re: [nanogui] Images not drawn (FLTK+nxlib app with nano-X)
From:
"Greg Haerr" ####@####.####
Date:
8 Feb 2006 02:09:44 +0000
Message-Id: <05e801c62c54$ad39f710$6401a8c0@winXP>
> I do not understand where GrUnionRectWithRegion calls are coming from and
none of my debug messages are hit except the ones in GrUnionRectWithRegion.
Is it some kind on nano-X algorithm or somewhere higher up?
Quick overview:
Api Prefix ------ Library API ------- Directory
Xxxx NXLIB nxlib/
Grxxx Nano-X nanox/
Gdxxx Engine engine
Each higher level call from NXLIB will always be implemented
using Grxxx Nano-X calls, which are then implemented
using the Gdxxx Engine calls. You'll want to make sure that
the DPRINTF is uncommented in nanox/srvnet.c::GsHandleClient(),
this will ensure you see all Grxxx calls, inbetween Xlib
and the engine layer. Each Xlib level API call is completely
implemented before returning, nothing is left until later, since
NXLIB can't know what the next Xlib API call might be.
> The first XSetClipOrigin() generates GrUnionRectWithRegion calls for each
line of the image and creates clipping rectangles for them (incorrectly,
source of the rounding problem).
I presume here you mean that the rounding problem is the image truncation
bug
we're working on?
Regards,
Greg
The second XSetClipOrigin() triggers redraw of the image (GdBlit) but
because of the previous problems, it is not drawn correctly.
Any ideas?
Martin
-----Original Message-----
I am getting stuck again.
After the call to devdraw.c::GdArea() and before the call to
devdraw.c::GdBlit()
there are calls to srvfunc.c::GrUnionRectWithRegion() for each segment
(line) of the image.
For some reason the parameter rect->width is rounded down (?) to 16 pixel
boundary of the image.
Where are these calls coming from?
Martin
-----Original Message-----
That is a good question!
I do not do anything. It is the job of the FLTK to draw stuff and I do use
double buffering functionality of the FLTK and it does draw in memory first
before it copies it to the screen.
It calls (thru nxlib) the devdraw.c::GdArea() to generate the image by
drawing it in memory(?) (with drawpoint() and drawrow()),
calls some clipping and offset functions that do not do anything (in my
case),
and then calls devdraw.c::GdBlit().
This I verified with printing a lot of debugging messages. There is no
question.
I believe that the image generated by GdArea is correct and complete.
The problem is in the GdBlit using clipping rectangles created for each line
(or set of same lines) of the image and that the 16-bit reminder of the
image width (in prc->right) is chopped off.
The GdBlit() falling thru to 'Partly clipped' area of code is actually
normal for my images and the 32x32 images do the same and show fine.
I am looking for the code that generates clipping rectangles used by GdBlit
for segments of the image, but I did not figure out where they come from,
but I believe that there is the problem.
Martin
-----Original Message-----
> I traced the code thru devdraw.c::GdArea and the image is correctly
drawn in memory.
>I printed the number of calls to drawpoint/drawrow with x,y locations and
it makes sense for the image.
> However, it then calls GdBlit and here for some reason it falls to 'Partly
clipped' area of code
I don't get it. GdArea doesn't call GdBlit.... Are you sure you're
debugging the
original GrArea call? GrArea uses GdArea, which always draws pixels
one by one, using drawpint and drawrow, like you state above. Are you
drawing into an offscreen window, and then using GrCopyArea, which
will use GdBlit??
Regards,
Greg
