nanogui: Thread: How pixmaps will work

: *cheer*
:  I worked a bit on this last night when I discovered the lack of any way
: to double-buffer.
: Will you set up a state where you can specify that a window have a
: written and a viewed page ?

	Not quite.  The general idea will be to have a "CreatePixmap" routine
that will basically allocate memory, and then the returned id can be used for
any of the drawing functions.  All drawing will be offscreen.  Then, when
the contents want to be displayed, a "BitBlit" routine will copy some x,y,w,h
portion of the offscreen bitmap to a specified window on the screen.
The destination window's clipping parameters will generally be used, although
the first implementation might not support clipping.

: Or should we create our own backbuffer by making two windows and show
: the one that's not written to by GrLowerWindowing it.

	No - the difference between a window and an offscreen bitmap is
fairly simple.  An offscreen bitmap has a w,h and bits associated with it.
OTOH, a window has an x, y, w, h and no bits associated with it.  Thus,
a window must be _redrawn_ from expose events whenever it needs to be
drawn, whereas a offscreen bitmap will never get expose events and must
always be copied (BitBlit'd) to a window.

OK?
:

A clarification:

	Not quite.  The general idea will be to have a "CreatePixmap"
routine
: that will basically allocate memory, and then the returned id can be used
for
: any of the drawing functions.  All drawing will be offscreen. 

	I mean here that all drawing to the returned id from CreatePixmap
will
be offscreen.  Of course, normal window drawing will be onscreen for the
unclipped
portions of the window.


 Then, when
: the contents want to be displayed, a "BitBlit" routine will copy some
x,y,w,h
: portion of the offscreen bitmap to a specified window on the screen.


Greg

> A clarification:
> 
> 	Not quite.  The general idea will be to have a "CreatePixmap"
> routine
> : that will basically allocate memory, and then the returned id can be used
> for
> : any of the drawing functions.  All drawing will be offscreen. 
> 
> 	I mean here that all drawing to the returned id from CreatePixmap
> will
> be offscreen.  Of course, normal window drawing will be onscreen for the
> unclipped
> portions of the window.
> 
> 
>  Then, when
> : the contents want to be displayed, a "BitBlit" routine will copy some
> x,y,w,h
> : portion of the offscreen bitmap to a specified window on the screen.
> 

Just as an aside.  You are basically talking about the difference between
the way window systems like Windows are implemented and systems like
Plan 9 are implemented.  I would recommend looking at Rob Pike's paper on
windowing.  It discusses the performance tradeoffs of this decision, which
are non-trivial.  I'll try to dig up the reference.

Later,
FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

> Just as an aside.  You are basically talking about the difference between
> the way window systems like Windows are implemented and systems like
> Plan 9 are implemented.  I would recommend looking at Rob Pike's paper on
> windowing.  It discusses the performance tradeoffs of this decision, which
> are non-trivial.  I'll try to dig up the reference.

One of the conclusions people using X a lot have reached is you want both
video memory and client side pixmaps depending on the purpose. I dont think
its actually a big issue for nanogui as most low end onboard lcd devices
and the like tend not to have acceleration and also to be UMA

> 
> One of the conclusions people using X a lot have reached is you want both
> video memory and client side pixmaps depending on the purpose. I dont think
> its actually a big issue for nanogui as most low end onboard lcd devices
> and the like tend not to have acceleration and also to be UMA
> 

I was referring more to the time/space tradeoff.  Keeping bitmaps offscreen
will require more memory, doing redraws will require more CPUs.  This
decision is more important in embedded systems than in larger machines.

Regards,
FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

: One of the conclusions people using X a lot have reached is you want both
: video memory and client side pixmaps depending on the purpose. I dont
think
: its actually a big issue for nanogui as most low end onboard lcd devices
: and the like tend not to have acceleration and also to be UMA


	Are you saying that we should think of two slightly different
types of pixmap memory allocations?  That of an off-screen (malloc()) memory
and a pixmap who's memory is actually the screen?  Or are you
saying that we should have server-side memory _and_ client-side memory
allocations?


	It would be possibly relatively easy to implement both types, either
way.


Greg

: I was referring more to the time/space tradeoff.  Keeping bitmaps
offscreen
: will require more memory, doing redraws will require more CPUs.  This
: decision is more important in embedded systems than in larger machines.

In both the X and MSWindows models, there are drawing methods that
allow either way to be used by the application programmer.  That's exactly
the point, in that a programmer can pick which method they prefer.  Now, 
in some situations, an offscreen draw is required to prevent flicker.  Also,
there are cases when a window wants to have "savebits" for the its'
contents,
maintained without the need to generate paint/expose events.  At this point,
I am implementing just the base level offscreen draw capability, which will
be required no matter which direction the engine or api's go.

Greg

On Fri, 15 Oct 1999 14:39:47 -0400 (EDT) you wrote:
>>  
>> One of the conclusions people using X a lot have reached is you want both 
>> video memory and client side pixmaps depending on the purpose. I dont think 
>> its actually a big issue for nanogui as most low end onboard lcd devices 
>> and the like tend not to have acceleration and also to be UMA 
>>  
> 
>I was referring more to the time/space tradeoff.  Keeping bitmaps offscreen 
>will require more memory, doing redraws will require more CPUs.  This 
>decision is more important in embedded systems than in larger machines. 

It's not as if it's something that is forced on you. But for many applications
offscreen pixmaps is a must to get decent performance.

If you're thinking about keeping window bitmaps offscreen when the window isn't
mapped, or when it is obscured, then I agree that it might hog resources.
And that's not something I would advocate for NanoGUI.

However, supporting off screen server side pixmaps is important for cases
such as when you use the networked version, and want to draw on a canvas
that will be copied to screen frequently, but that may be fully or
partially obscured by other windows, and that will be partially updated
frequently. In those cases you certainly wouldn't want to draw client
side, and send the entire image over the socket every time it should be
updated.

Regards,
Vidar Hokstad
VP of R&D,
Screen Media

> >I was referring more to the time/space tradeoff.  Keeping bitmaps offscreen
> >will require more memory, doing redraws will require more CPUs.  This
> >decision is more important in embedded systems than in larger machines.
> It's not as if it's something that is forced on you. But for many applications
> offscreen pixmaps is a must to get decent performance.

Vidar is right.  Nothing suck up more time that writing to screen-memory.
keep in mind that you cant write to display memory while it is being read by some
other device.
I read somewhere ( in a book my Michael Abrash ) that you only get 10 - 20 % of a
complete cycle to write to memory on.
This cause a rather big delay, since the cpu usually wait until it is allowed to
write to that memory.
Offscreen you only get the memory refresh penalty, and the blit itself is so fast
you usually manage to blit everything in that small amount of time we got before
memory is being read again
Keep in mind I am a little out of date on the hardware side, static ram might make
my knowledge obsolete. =)

-Richard