[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 22:11:53
Message-ID: 201012141412.19140.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday, December 14, 2010, Benoit Jacob wrote:
> 2010/12/14 Aaron J. Seigo <aseigo@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.

the needs of webkit, gecko and qml are not diverse. that's kind of the entire 
point of what i'm trying to get across here :)
 
(we could also talk about Calligra, and i'm fairly confident it would fit into 
this category as well, but i haven't done enough looking into the specifics of 
it to comment with accuracy)

> Different users have different priorities. For example, Gecko wants
> pixel-exact rendering, which other users might not require. Also,

this is no different from webkit and qml.

> 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...).

this is no different from webkit and qml.
 
> 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.

i think you are mis-analyzing the reality of the implementations. now, i could 
definitely be wrong, but i have yet to come across an actual difference in 
needs. if you can present one, then that would destroy the theory i am 
espousing here. so far, however, the "it's really the same scene graph 
requirements" theory fits the facts as known.
 
> Notice how general-purpose scene graphs have been tried in the past,
> and the world has settled for more imperative, lower-level APIs:

that's because the applications using those lower-level APIs have different 
needs driven by their data models. in this case, the data models are 
equivalent (in terms of scene graph needs). a lower-level API would be fun (we 
already have OpenGL, OpenVG (for whatever it's actually worth in reality)), 
but we can probably do one better here by giving something that drivers can 
agressively optimize against. it's also easier to come up with a bespoke, but 
shared, scene graph than to get a low level graphics API "right". far, far 
easier.

> * Direct3D retained mode never took off, but Direct3D direct mode did.
> * VRML and X3D never took off, but WebGL is taking off.

it's a false analogy. we're not talking about games or true 3D or a use case 
target set with variance in data model. we're talking about a 2.5D canvas with 
(essentially) identical features paired with equivalent data models.
 
> > 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. 

which is fine. all of those uses end up decomposing to the same kind of data 
model for the scene graph. if they don't, they really can't/shouldn't be done 
with HTML5 (or QML) and should be shooting for full WebGL or whatever.

> 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.

precisely. and, magically, we can share that scene graph between 
implementations that need to provide that exact same 2.5D canvas 
functionality.

> 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.

such as? (and if you say "video" i will be unimpressed ;)

> And ideally, we should come up with a fully satisfactory answer to
> Direct2D, not just something to support a few web technologies.

that's not actually going to help driver teams much, and it's a huge 
undertaking.

realize that Direct2D is basically ignored by driver writers. they work on 
optimizing the usage patterns seen in the 3D layer that Direct2D maps to. now 
that ie9 is using Direct2D, driver writers are starting to optimize for the 
state+shader profiles that end up in the ie9->Direct2D->Direct3D path.

so having a Direct2D style API will get us zero in terms of better 
performance, for the same reason "using OpenGL" isn't enough on its own. it 
will make it easier for developers to target .... but in this specific use 
case a common scene graph with common shaders would provide similar advantages 
for the target users (gecko, webkit, qml, etc) while providing opportunity for 
deep optimizations, right down to the drivers.

> > 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.

i think you'll find that the requirements here are identical.

> > 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.

right, and a Direct2D-like API isn't going to help one bit with that. turning 
our backs on an opportunity to, in very fundamental ways, provide the 
necessary tools to really provide good performance just because there will be 
complex needs later would be a mistake imho. it amounts to trying to optimize 
for a 1% use case that can not actually be optimized for (different kinds of 
games have wildly different requirements of the 3D API) at the expense of the 
99% use case that we can optimize for without busting the budget.

trying to create a generic 2D graphics API that we all agree on won't actually 
equate to driver optimizations like a shared scene graph + common shaders 
approach will, and it will be very expensive to accomplish.

-- 
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]