[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: plans for a free, OpenGL-based equivalent to Direct2D ?
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-12-14 21:08:46
Message-ID: 201012141308.46676.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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.

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 (each of 
which have different scene graph design requirements), a scene graph that is 
good for one will be good for the other.

QML, HTML and Calligra all have similar:

a) complexity in terms of spacial representation in the rendering (essentialy 
2.5D)

b) similar node density (well, Calligra will almost certainly have a lower 
density, but having overhead there is fine)

c) identical requirements for node transformations

d) idetical node content (text, geometrical shapes, brushes, pixmaps, video, 
..)

together, that means that a scene graph that is done reasonably well for one 
of them should be effective for the others. for Qt, it would make very little 
sense to have one scene graph for QML and another for QtWebKit. (in fact, i'd 
go so far as to suggest that it would be stupid to do so given that web 
content within QML is going to be a common enough use case.)

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.

the difference in layering models (or more specifically, the rather 
"interesting" one in HTML) is probably the biggest difference, but that 
shouldn't impact the choice of scene graph usage.

and in case you feel i'm talking about my posterior, i did go ran this by 
people who do this for a living (and no, not people at Qt) to make sure that 
what i've been learning about these things as well as the above conclusions 
are accurate. :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]