[haiku-appserver] Re: private development
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 24 Mar 2005 23:23:09 +0100 CET
Hi,
> > Another approach to intergating Painter would be to create another
> > derived DisplayDriver class, that implements all the existing
> > DisplayDriver functions on top of Painter. Would this be a better
> > thing
> > to do? The clipping of the client seems to be passed by the
> > DrawData
> > object that each call gets, right? This reminds me of another
> > question
> That's pretty much what I had envisioned when it comes to integrating
> Painter. I was thinking that the DisplayDriver class would have a
> Painter member object which it called for various methods.
> DisplayDriver could handle all the messiness in setting Painter's
> state. I'm not very familiar with Painter's internals, but the only
> major thing that I would possibly want to change in it would be to
> see
> that it would call the virtual functions that are implemented by the
> individual subclasses so that we can still take advantage of HW
> acceleration. Does this sound reasonable?
Yes, of course. I see a relatively clear path in front of me, which is
a good and motivating feeling. As far as HW acceleration goes, if we
want AA drawing, we would probably need a different HW acceleration
from what there is now. Let's see about that later. One more important
problem is that Painter right now only supports 32 bit frame buffers.
This is not good for VESA mode I would guess. Another thing to worry
about later... it's just a lot of work to redo all drawing modes for
different colorspaces, but it's straight forward work. Anyways, I
should stop talking.
Best regards,
-Stephan
Other related posts:
