[haiku-appserver] Re: drawing thread
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 15 Oct 2004 16:57:24 -0400 EDT
> > Yes we are. Double-buffering is internal to the display module and
> > is
> > not a requirement -- AccelerantDriver is currently not double
> > buffered,
> > for example, even though I'm assuming that it eventually will. The
>
> It can be seen we haven't talked in a long time. :-)
> I don't know how double buffering at DD level could work. In fact,
> I'd really like you to explain
> us, cause' you're making me very curious.
The actual DisplayDriver class doesn't actually do anything with
respect to double-buffering -- it's actually up to the subclass. I'll
use the now-obsolete ScreenDriver and DirectDriver as examples.
DirectDriver's architecture is set up such that gfx calls are written
to a BBitmap and updated rectangles are put into a FIFO pipe which the
updater thread pulls rectangle. AcquireBuffer calls return a pointer to
the BBitmap. As such, it very much is double-buffered. Calls in
ScreenDriver (before I really broke it) wrote directly to the
framebuffer. IIRC AccelerantDriver calls HW-acceleration functions
where appropriate and otherwise uses software calls to write directly
to the frame buffer.
> My opinion:
> I think you are wrong. DisplayDriver is a drawing framework. How it
> gets things done it's its
> business, it can directly use hardware acceleration or use CPU to
> draw in buffers.
> You do not need to lock it to use its methods. Instead, those
> methods should get a buffer and a
> drawing context. Based on those arguments, it draws within specified
> clipping region inside buffer.
> This way you need not to lock DD, and in a multiprocessor environment
> is could be a very good thing
> as another CPU could safely draw onscreen the contents of other
> windows.
> Double buffering needs to be controlled by window manager because
> it is the one that issues
> _UPDATE_ requests. When redrawing of a window is needed, it can very
> easily look into window's
> offscreen buffer to see what valid areas it has and what exactly
> needs to be actually redrawn.
What about when two different threads need to write to overlapping
areas of the screen? An excellent example would be when a developer
goofs and overlaps two sibling BViews. At that point, they each can't
rely on the data in the overlapping areas and things get really screwed
up or keeping both copies up-to-date gets pretty hairy when screen
composition is done. Parallel access like what you describe is
something that I want for after R1 -- not before. Locking is necessary
because we are heavily multithreaded.
> Locking is needed only when double buffering is disabled or when we
> go out of memory for the double
> buffering process. Still, in the second case we could release the
> memory of some minimized or rarely
> used windows.
>
> > BitmapDriver, for example, is also not, but for obvious reasons.
> > Any
> > time we have two threads sharing access to a common resource, such
> > as
> > DisplayDriver, there is a need for locking -- unpredictable results
> > occur otherwise.
>
> Guess you have a different opinion now. :-) Isn't it? :-P
Not at all. My opinion has stayed the same. What you are proposing for
changes to the DisplayDriver system is more like what Longhorn has
done, and the entire system is definitely something that will work, but
it's also an order of magnitude different from what's in place. I hate
to sound like I don't care about what you think -- I do -- but we need
to stick with what we've got. If we keep doing major redesigns of
significant portions of the app_server, we will _never_ finish. At this
point, that is the major goal I've got in store is to push so that we
actually have an alpha sometime next year.
> One more argument for Poller thread be the one to do move/resize/
> blit.
> It does not have _any_ impact on interface responsiveness. Poller
> execution path is resumed only if
> all regions are calculated and all windows have their surface drawn
> with _view_color, or better
> their valid offscreen surface blit in case of double buffering.
> So you see, either we use a different thread for doing all move/
> resize/blit operations, or do that
> with every ServerWindow thread and hugely complicating things, _or we
> use_ Poller thread for this
> job, this thread must wait for all regions to be rebuilt and all
> windows/views to draw their initial
> canvas, before processing user input actions.
> > Unless I've
> > completely missed the boat, the main problem in moving and resizing
> > is
> > the resource hog that it is. Even on my new machine, it's still
> > painfullly obvious in the slowness of moving one window over
> > another as
> > opposed to just moving one around.
>
> That is because we use BView as a back end. When DD functions will
> work in conjunction to
> AccelerantDriver this won't be noticeable anymore.
I realize that probably 99% of it is the horrible slowness of the
ViewDriver. Considering that DirectDriver will be our new testing
driver once I can figure out how to fix its stability problems, I'm
hoping that things will be painless using it without any hardware
acceleration.
> While you are invited to do so, I really don't think you'll find a
> problem with clipping code. That
> code took me some time to complete and I checked it over and over,
> performance wise also. IMHO:
> there is very little room for improvement and if you want to get rid
> of this problem I think you
> should have AccelerantDriver working.
I'll keep that in mind. Thanks. :)
--DW
Other related posts:
