2010/12/14 Aaron J. Seigo <ase...@kde.org>: > On Tuesday, December 14, 2010, Benoit Jacob wrote: >> These days, the needs of web engines are easily as complex as those of >> complex games: between <canvas>/2d, css, and svg, there's plenty of >> ways that a web page can be a complex 2d game :-) Then throw fonts >> into the mix. > > er ... ok, so .. pretty well every modern game out there uses a scene graph. > it's a term with a broad definition, though. so it's not a matter of "is a > scene graph a good enough approach": it is. the question is whether a given > scene graph implementation provides the right qualities (and, for easy of use, > API) needed for the use case. given that QML is functionally equiv (and then > some) to HTML5 in this contenxt and that the QML scene graph fully accelerates > QML, it's quite evident that the needs would be taken care of. > > scene graph appropriateness is all about the data model and how it is used in > rendering the final results. which is why you have different kinds of scene > graphs for different types of games.
Right. I don't doubt that for any given use case, there's a way to address it with a suitable scene graph. What I doubt is that there's a scene graph model that will satisfy all the diverse needs that have been mentioned in this thread. Different users have different priorities. For example, Gecko wants pixel-exact rendering, which other users might not require. Also, Gecko wants a lot of control over fine details of font rendering, and wants all that to interoperate well with other OpenGL contexts (compositor, webgl...). So if we're going to share code here with anyone else, that's not going to take the form of a fixed-function scene graph, that will have to take the form of a more direct and imperative API. Notice how general-purpose scene graphs have been tried in the past, and the world has settled for more imperative, lower-level APIs: * Direct3D retained mode never took off, but Direct3D direct mode did. * VRML and X3D never took off, but WebGL is taking off. > > for QML or HTML or an office suite you're looking at a rather generic use case > that allows for very few assumptions about the data model (relative to a > typical complex game) mostly due to a very generic API. unless you wish to > optimize your web canvas for car racing or for first person shooters Unfortunately, we have to optimize for quite convoluted use cases. Lots of games, fancy UIs, and graphics-intensive web apps are being built using canvas 2d. For a 3D first person shooter, the right way is to use a WebGL canvas instead, not canvas 2D; but there's plenty of 2D games for which canvas 2D is the right tool. Again, a specially tailored scene graph could support canvas 2D well. But it would really be a pity to only accelerate canvas 2D. In browsers alone, there's lots more 2d content to accelerate than that. And ideally, we should come up with a fully satisfactory answer to Direct2D, not just something to support a few web technologies. > QML, HTML and Calligra all have similar: > > a) complexity in terms of spacial representation in the rendering (essentialy > 2.5D) Gecko has lots of unit tests requiring pixel-exact drawing, and requires very fine control over font rendering. Don't know about the others. Just an example of something that a general-purpose solution might easily overlook. > that same, btw, can not be said for complex games and HTML5 or complex games > and QML. you can certainly make games with them, but for complex games (in > terms of what the games industry considers complex, not what we might as HTML > or desktop app monkeys :) it's a whole different kind of scenario. While that's a matter of fact today, we don't want to hardcode it. There are proprietary solutions out there, like Flash, that want to get ready to allow for very advanced online games. We have to make sure that the same can be achieved using open web technologies and no plugin. Benoit >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
