[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:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2010-12-14 22:54:19
Message-ID: AANLkTimMEX0ocgg73h1E_okpaHCEH0Gz-Qh_NgLx-BkH () mail ! gmail ! com
[Download RAW message or body]

2010/12/14 Aaron J. Seigo <aseigo@kde.org>:
> 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.

WebKit, Gecko, and QML may have the same theoretical needs. When comes
the time to write an implementation in finite time, will they want to
make the same trade-offs and compromises?

My point is that designing a scene graph engine requires to make
compromises, to favor certain use cases over others.

By contrast, a lower-level imperative API such as Direct2D can be
implemented with far fewer compromises, can be more agnostic wrt usage
patterns. That's why in practice that's the level at which people
share code on a large scale.

Notice that such a lower-level API would itself be a good foundation
on top of which to build scene graphs.

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

My concern is the difference between this theory and the reality when
deadlines approach. As I say above, a lower-level API would avoid
having to make trade-offs that will fail to satisfy everybody.

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

That's exactly where we disagree. Designing a high-level API involves
lots of design choices, and implementing it involves trade-offs. For a
lower-level 2d API, we already have a quite successful example with
Direct2D, and building on this experience we could get an even better
API.

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

Everything in a web page needs to be accelerated! Text, images, svg,
you name it.


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

I just disagree with the notion that accelerating 2D requires drivers
to optimize a lot for this use case. Sure, lots of things you'd like
to do with 2D are going to be slow to do on the GPU, but that's not
something that driver implementers can fix. For example, frequently
uploading small textures is slow, and that can't be fixed. So a good
2D library must be good at deciding what to accelerate with the GPU,
and what not to.

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

I don't see why you say that. it's nontrivial to design graphics APIs
that allow for serious hardware acceleration without too much overhead
or inefficiency. Direct2D is such an API.

Benoit

> 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
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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