Re: LiMux student "kick-off"

Hi Ptyl,

On Wed, 2014-09-17 at 15:45 +0300, Ptyl Dragon wrote:
> ok, then we'll use GL2.1. we'll make sure we use only API used in ES 2
> too.

        The whole situation around different GL versions vs. mismatching GLES
versions etc. is too horrible for words =) my hope is that we could
support OpenGL 3.2 - to get a good Mac baseline, and fallback for Linux
where we can.

> We need simple thing. after all, we are not making a First Person
> Shooter. For starters we are just making a 2d rendering engine

        =)

> I don't think i follow. Is the idea is to keep using the current
> rendering mechanism, and just use OpenGL to render lines and
> rectangles?
        I guess that's a good first start.
> in any case, for tiled rendering, we want to render all the elements
> in the tile together and at once, per tile. If this is all done by
> OpenGL, it would ensure the performance we require. 

        Sure - doesn't that follow from a pure OpenGL renderer ?

> Also note that in tiled rendering, notions like copyArea are
> irrelevant, as by definition, each tile contains nothing of the
> neighboring tiles.

        The copyArea stuff is interesting; my hope is that we could get rid of
that mess; however that intersects with some of the paint / timer work
that is also planned for the interns - since we currently defer
re-painting of various things to a timeout.


> 1. what exactly is the thing that is already working on desktop?
> (explanation + code pointers)

        We have some nice cross-platform GL context creation going on that
Markus created I believe (sadly he is away from a PC / E-mail from now)
- which should be easy to re-use.

> 2. what are VCL plugins? Does VCL have a plugin infrastructure ? does
> it use dynamic linking (if so, it won't work for iOS)? it would be
> great if someone could direct me to some code pointers that show how
> this plugin infrastructure works

        The backends have the vcl/inc/ API including salgdi there to implement;
but on Linux we can choose dynamically between many of these backends
eg. KDE3, KDE4, GTK2, GTK3, raw-X etc.

> 3. I'm not sure if i saw the OpenGL development plan, so i'd be happy
> if anyone could direct me to it.

        I've just forwarded you some rough notes.

> I want to learn all there is to learn, so to be able to actively
> expedite this front (i.e hack the way myself)

        Sure - so I think one thing we need to get unwound (and that you
identified and raised) is the issue of immediate rendering.

        If we go for immediate rendering; then we need to render to an
off-screen frame-buffer, and then we can fool around with copyArea
etc. ;-) [ this is not such a terrible thing to do of course but not
ideal ].

        If we instead collect damage from immediate rendering, and then just
trigger a full re-render of that area using an OpenGL context - then
that might work better: and overlap with tiled rendering.

        In the end / long-run we'd want to rid ourselves of immediate
rendering, and emit damage events not in window co-ordinates but
document co-ordinates (IMHO etc.). But of course - as a first step
killing all immediate rendering is a great idea.

        Chris Sherlock was having a look at this problem in the past - with an
aim of stopping Windows deriving from OutputDevice - such that it's not
even possible to go rendering on Windows in an un-controlled way at any
time.

        It would be great - Noel - perhaps this is something you could do ? =)
if we could find all instances of method calls on OutputDevice that
occur in a method that is not a child of some 'Paint' or render
method ;-) [ that would give us a hit-list ] - I'm not sure if that is
Clang-plugin-able ? ;-) [ how is the view of the call-graph from there
].

        Ideally all rendering is done to a transient context that is passed in
only for the duration of the rendering call.

> As Markus is now on vacation, perhaps someone else can help me with
> these issues? I don't want to stall a month now, as I believe we can
> make progress in this time frame

        Does any of the above help ?

> If it will make things simple, efficient, and maintainable, then all
> good with me, again, i'm an OpenGL noob, and i don't know where the
> performance bottlenecks are Still, to prevent a waterfall scenario,
> let's wait with the gradient handling, and the drawing layer
> optimizations in general, until we have things working in VCL without
> it.  
        Personally, I'm completely with you on: "First make something work" ;-)
then we can go for performance - but it'd be great to avoid making big
design / performance mistakes at the outset of course/

        Hope that helps,

        All the best,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot