[haiku-appserver] Re: user needs to know about the clipping region?

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 25 Nov 2005 21:06:24 +0100

Hi Michael,

thanks for taking the time to think this through.

> > Stick with the clipping based approach, but how about an offscreen
> > buffer  in main memory for just the parts in the frame buffer
> > with transparency?
> 
> Not that I understand every aspect here, but I think that this is not as
> easy as it sounds. As far as I understand it, you need to have the
> current background to draw something transparent over it. If this is
> the case, this would either require to keep the whole frambuffer in
> main memory (reducing this approach to a double buffer), redrawing all
> parts below the new transparent area to build up the backgroud (which
> would take a long time for bigger areas) or to fetch the background
> from the graphics card (which is terribly slow).

You don't have to have the background available to draw something 
underneath the transparent area unless what you draw needs to be alpha 
blended itself, like in some cases when drawing text or anti-aliased lines. 
So your observation is correct for some cases.

My thinking is simple: Why does it flicker so badly in R5 or ZETA, when you 
drag something transparent, and stuff behind the transparent bitmap is 
drawn? It looks like BeOS has a backup of the background of the transparent 
drag bitmap in main memory, and before anything is drawn there, the 
background is restored, the drawing done and then the bitmap is composed 
back on top of it. Doesn't this sound very clumsy? There is no other 
explaination. In my opinion, we could introduce a mechanism to "rout" 
graphics calls either to the framebuffer or to main memory, depending on 
wether we want to show something transparent on top of it. My proposal is 
just an idea for the implementation. Extended from just dragging 
transparent bitmaps to other transparent drawing on the server side. Like 
anti-aliased edges of a window decor's corner.
The background as it would be displayed in the framebuffer without any 
transparent overlays could be contained in a second main memory buffer. 
This way, having to transfer stuff from graphics memory to main memory 
would be greatly reduced.

> You can only keep the "parts with transparency" in a main memory buffer
> if you know beforehand what parts will have transparency. With the
> example of dragging a transparent bitmap this is certainly not the
> case. And getting or redrawing the background everytime when a user
> starts dragging that transparent bitmap around is a bit overkill I
> think. Just imagine the situation where you select something in
> ShowImage and drag it out to make a bitmap clip. The background changes
> with every move.
> Just my concerns about this. Or do I just miss something?

The implementation of dragging a ShowImage bitmap clip seems to be exactly 
the horror scenario that you describe :-). With the exception that you 
don't need to transfer parts that you have previously transfered. Assuming 
you have dragged the bitmap all over the screen, and no part is redrawn in 
the meantime, you would not have to transfer anything again.

But for the case that something is redrawn... my idea is to have a special 
clipping for that, so that drawing commands can be routed to the main 
memory "backup".

Current R5 implementation (from observation):
- get a drawing command
- ups, there is a transparent overlay where I want to draw
- restore backup of that area
- do the drawing
- refresh backup
- put the transparent overlay back on top

My proposal:
- get a drawing command
- clip to non-transparency containing parts on screen
- draw those directly on screen
- clip again to transparency containing parts on screen
- draw those in the main memory backup (possibly having to make the backup 
first)
- do the alpha compositing with the frame buffer as target

As you see, this saves a few (of the expensive) steps, and completely 
avoids flickering. When this concept is applied to window borders, there 
would not have to be transfer from graphics memory. When any window frames 
change, the transparent region would be included in the dirty region.

There would have to also be a dirty region tracking for the frame buffer 
backup. Ie, when there is drawing in the frame buffer for non-transparency 
containing parts, but we already have a backup for that area, it would 
simply get marked dirty.

Best regards,
-Stephan

Other related posts: