[haiku-appserver] Re: "Painter" progress

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 14 Jan 2005 23:51:16 +0100 CET

Hi,

>       First I'd like to wish you a happy year full of accomplishments! 
> May 
> all your dreams come true.

Amen to that.

>       I would like very much to use AGG as a back-end for app_server 
> drawings 
> because of its *working* :-) state and features. However I'd like to 
> ask 
> you some questions and express my opinion about.

Of course.

>       My first question would be... do we need all AGG features? Should 
> we 
> include all the files/features AGG has or just the ones we are 
> interested in?

Since AGG is much based on templates, almost everything is implemented 
right in the headers, which basically means you compile only the stuff 
that you actually use. That being said, I don't see something in the 
way of leaving out certain functionality. We should not concern us with 
that though, unless we plan to go portable... :-)

>       Can you take advantage of 2D acceleration found in hardware? 
> Because 
> you _must_ if you want Painter to be the drawing back-end for 
> app_server.

There are different options for hardware acceleration:

1.) Using accelerated calls for special (but very common!) cases of the 
drawing functions, like drawing BRects and vertical/horizontal lines.

2.) Using alpha blending in the graphics chips to compose AGG generated 
scanlines right into the frame buffer. I will try and write something 
up about how AGG works, maybe a Newsletter article?

> Stephan Assmus wrote:
> > Clipping, coordinate 
> > system scaling and translating are all supported to mimic BView 
> > behaviour. The graphics state stack can be implemented by 
> > refactoring, 
> > or it might be a better idea to implement this elsewhere.
> 
>       Yes, I think that is good idea. In fact we all do, because our 
> graphics 
> state stack is already outside the graphics engine (XXXAccelerant 
> classes). :-) However our XXXAccelerant classes get a pointer to the 
> graphics stack and use the infos found in there. Now, I suspect AGG 
> uses 
> the same mechanism and a simple translation between the two formats 
> should be OK.

Basically, the Painter class in its current form shows how the BView 
drawing can be implemented in terms of the AGG functionality. It means 
a lot of duplication. So when it gets integrated, it will most likely 
be ripped appart again, read "refactored", to really fit into 
app_server. But at this point, all the details of BView style drawing 
will have been investigated, and the code will be known to work.

> > I have not implemented BBitmap drawing yet, but I do offer 
> > cached font rendering. The code is largly unoptimized as of now, 
> > and 
> > BView is arround 12 times faster drawing into a BBitmap than my 
> > Painter. Painter scales better though, so with lots of clipping and 
> > line width > 1, Painter catches up to being about 2 times slower. 
> > However, at that speed, it does have full anti-aliasing support.
> 
>       That's very good to hear. However IMHO you must be at least 15-25% 
> faster than BView because BView still has the communication overhead 
> with the app_server.

I agree with you, but for now, we should not concern ourselves with 
that too much. It needs to work first, which means all issues are 
known. Then we can start thinking about making it as fast as possible. 
The pressure right now is to deliver a working app_server, because it 
means a holdup to so many other parts of Haiku. To make it as fast as 
the original app_server is not the primary focus for its first working/
usable incarnation. The focus is to *get* a first working incarnation 
at all.

> > I don't know if this is going to be a hot topic or not, but IMHO, 
> > Haiku 
> > would be more of an eye-catcher, if it supported anti-aliased 
> > drawing 
> > natively. The problem is of course speed, which I intend to address 
> > by 
> > introducing special optimizations for drawing straight (horizontal 
> > and 
> > vertical) lines. I think this would speed up the drawing for normal 
> > GUI 
> > tasks quite satisfactory.
> 
>       Aha. You're also thinking about 2D acceleration here?

Yes, see above.

> > However, I think having a fully anti-aliased graphics engine for 
> > Haiku 
> > might be better anyways, it won't look as dated when it "comes 
> > out".
> 
>       It's a good idea.

All the other guys are thinking about the same stuff, so with it being 
available so easily, the only questions we need to concern ourselves 
with is a) how do we stay compatible with the effects of BView 
drawing_modes and b) how do we maintain a fast GUI.

> > The Painter class can be used by the app_server in a simple way: A 
> > Painter object is attached to an instance of a "RenderingBuffer", 
> > which 
> > can be a BBitmap or the frame buffer of a graphics card. After 
> > that, it 
> > will offer anything that BView offers in terms of drawing functions 
> > and 
> > clipping minus some of the redundant functions that can be 
> > implemented 
> > elsewhere. The Painter handles all translations from native Be 
> > objects 
> > to AGG internals like BFont, BShape and BRegion etc.
> 
>       Why BRegion? I think by doing that transformation you loose 
> valuable 
> CPU cycles. And I don't understand, BRegion is transformed into what? 
> (don't know the actual name)Alpha Map?

What I meant by converting BRegion was that the clipping is given to 
Painter using BRegion, while internally, some AGG representation is 
used. These conversions are not something that we need to worry about 
too much. For the first working version of app_server, I would even go 
as far as saying that all other BBitmaps could be converted to 32 bit 
before drawing just to get "done" faster. This is really something that 
can be changed and implemented later without *any* trouble. It could 
even be done by someone having little knowledge of the rest of the 
app_server design.

> Keep up the good work!

It's going a little slow for me, because I lost my Notebook, which 
means I cannot work in many situations that I used to work before, like 
in the train to my girlfriend and while I'm staying at her place. I 
have to keep my other projects going as well. But I will try my best, 
the first steps are taken...

Best regards,
-Stephan


Other related posts: