Le 23/02/2012 21:07, Ryan Leavengood a écrit :
I don't see how it is compromised. The drawing code living inapp_server side means it can be replaced by an hardware accelerated version (think shaders) when we go for hardware acceleration, and this without having to change a line of code in the apps, or even recompile them. Look at what happens when you run an old BeOS app on Haiku : you get the antialiased drawing, for free and without a change to the app.In general I think we just need to experiment and see how things work. I will say it probably does not make sense to compromise the much more common local use to more easily support the relatively rare remote connection.Still, here's the current situation with Webkit: Webcore gfx interface [1] -> Haiku native backend [2] -> BeAPI drawing calls [3] -> app_server [4] -> AGG [5] [1] Fast moving interface [2] Incomplete and not up-to-date [3] Missing some functions required for full standards compliance, which would need to be emulated [4] Separate process - adds some overhead for each primitive drawn [5] Probably contains the missing bits mentioned in 3, but they're not exposed through the BeAPI. In the end, just renders into a chunk of memory
A valid option would be to extend the BeAPI to add what it lacks as far as drawing commands goes. It is not too much work as AGG should provide the code for most of them already. So it could go that way :
Webcore > Skia wrapper sending commands to BeAPI > app_server > AGG.That solves the problem of getting out of sync with webcore, and allows to use the same architecture as other apps, as a nice side effect you may get to add useful things to the BeAPI for other apps to enjoy.
You need to share things between processes at some point, sharing the drawing commands through the app_server link seems simpler to me than doing all the drawing yourself then sharing the whole bitmap. The bitmap would still have to be blitted to screen somehow, if you do it that way. You could use BDirectWindow, but then your drawing system must accomodate for all video modes Haiku can work with (256 colors, 16 and 32 bits, possibly more in the future). And if you don't do that, a conversion of the bitmap has to happen somewhere, so it will be even slower. On the other hand, the BeAPI calls will draw directly to the screen buffer (with double buffering involved), and there will be no copy at all, and it works in any video mode. You could get the same performance with video overlays, but these don't work on most modern graphic cards with our drivers, and they don't with VESA, either.
-- Adrien.
