Hi all, First I'd like to wish you a happy year full of accomplishments! May all your dreams come true. Stephan I must say I'm quite impressed seeing those images, especially because there is clipping involved. Great work! 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. 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? 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. 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. > 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 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? > 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. > 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? > There will be no support for BPictures, as I figure BPictures are > recorded drawing command sequences, so inside app_server, BPictures > should be decomposed to what the Painter supports anyways, please > correct me if I'm wrong. There is nothing to correct in this affirmation. :-) > sorry for spamming the list with that attachment. BBitmap drawing is > figured out as well now (scaling and cropping). There is no really hard > work left now, except for filling out all the details, like > implementing every drawing_mode, taking care of different alpha > blending behaviour, and implementing all the color spaces. Shaping up > the design should not hurt either. Once I'm a bit further down that > road I will commit my work. Uhh... nice to hear that. > Nevertheless, maybe we can start to think about integrating this with > app_server. I'm totally open for discussion on every aspect of this > task and the Painter design itself. I think DW will be the one to help/ask in that direction. Keep up the good work! Bye, Adi.