nanogui: Thread: Blitting

: > characters for speed.  So, on a refresh, the current background
: > color is fillrect'ed to the display, then the non-space characters
: 
: That makes it flicker. You dont do that. 

Whoops

You just skip updating chars that where
: space and are a space now

Only one problem...  If the area really is in need of
refresh, someone's got to draw the background sometime.
Also this requires two copies of contents: before and after screen data.

So now I remember how to do it...  You add the
non-update area (area not included in the expose event)
to the current clipping region, _then_ fillrect to the background
color and don't draw space characters... No flicker, and 
only the screen parts that needed updating ever get painted

Greg

Hi, 

I've an application which will have two windows in the exact same 
co-ordinates.  Obviously only one will ever be on screen at any one 
time, but there will be a need to update one, while the other is on 
screen.  I assume I need to implement the blitting screen drivers 
for this.  The updates needed for off screen drawing will be simple 
functions like GrRect, GrFillRect and GrText.  

Is it a matter of implementing functions like those in fblin8.c.  When 
it comes to bring the hidden window onto the screen I assume some 
kind of memory to screen function should be called??  Does there 
have to be a draw pixel, draw horz line, draw vert line and get pixel 
for storing off screen and drawing it back to the screen again??

Thanks,
Fergal

> I've an application which will have two windows in the exact same 
co-ordinates.  Obviously only one will ever be on screen at any one 
time, but there will be a need to update one, while the other is on 
screen.  I assume I need to implement the blitting screen drivers 
for this.  The updates needed for off screen drawing will be simple 
functions like GrRect, GrFillRect and GrText.  

You can't draw to a window that's offscreen.  Use NewPixmap
for that.  One way to solve this problem is to implement
the EXPOSURE event for each window, and only draw
the window in the EXPOSURE event processing.  Then you
don't have to worry about any of the above.



>  it a matter of implementing functions like those in fblin8.c.  When 
it comes to bring the hidden window onto the screen I assume some 
kind of memory to screen function should be called??  Does there 
have to be a draw pixel, draw horz line, draw vert line and get pixel 
for storing off screen and drawing it back to the screen again??

To copy a pixmap to the screen, you would use the GrCopyArea
function from the pixmap to the window.  This will end up using
the screen driver blit entry point, like those in fblin*.c.  It doesn't
have anything to do with drawpixel, horzline, etc.

Are you running a special screen driver?


Regards,

Greg