Re: LiMux student "kick-off"

inline

On Wed, Sep 17, 2014 at 8:17 PM, Michael Meeks <michael.meeks@collabora.com>
wrote:

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

Regarding this, from the little i've learned so far of OpenGL, the main
thing would be to avoid use the OpenGL extensions and API calls that don't
exist in ES, which from what i know so far (and i might be wrong) include
using only triangles, lines and dots (which might not be ideal for the
polypolygons stuff, but is necessary for porting to ES), refrain from using
GLSL 4.x stuff, possibly avoid GLU and GLUT (i think they are unsupported
in iOS) and the likes. In other words, whatever feature of OpenGL we use,
we should first ensure it exists in the target OpenGL ES version we choose,
on Android and iOS.


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

yes. That's why i thought it was tiled rendering is the simpler case,
because once we agree the target is to use a pure GL renderer, then doing
the quasi mode (i.e. use the existing solution and "augment" it with
OpenGL) becomes a bit of a spaghetti over the pure OpenGL  solution - i.e
rendering in OpenGL, then copying to non OpenGL while still using a double
buffer for OpenGL, and maintaining the existing VCL rendering in parallel.
In my mind, what would have worked better is to avoid the quasi mode, do a
pure OpenGL rendering, then integrating it in Desktop via a desktop tiled
rendering mechanism....though i guess that's a waterfall in itself. Still,
if we focus on that, we'd get to Android high performance support faster,
and i think that in many ways, that should be the goal, because of all the
OSes on which libreoffice runs (in one way or another) android suffers the
worst rendering performance. I would think, the other platforms can "wait"
since they are getting decent performance already. But i can see why you
would disagree with me on this.

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

in our iOS implementation we solved the timer issues by considering them as
damaged areas, similar to areas changed by editing. Viewer only
functionality may not require this by default, but still, it can solve this
without getting rid of the timers. Still, i agree that in the long run, the
timer thing needs to "go".

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

great!

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

got it

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

thanks.
i looked at them. Possibly, i will need a hands on review of it, to know
where CloudOn / myself can bulge in.


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

as i mentioned above, possibly the immediate rendering can be considered as
a special case of non immediate rendering, via a tiled rendering mechanism
for all platforms. possibly this will take us forward faster, though we'd
be skipping over a few milestones in this fashion, which is kind of a
dangerous waterfall.

Still, again, if we get it working on Android, we could incrementally add
it to other desktop OSes, while still seeing "progress in the wild".

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

again, i think the solution should be to move to tiled rendering on all
platforms. But then again, moving all platforms to tiled rendering, raises
the effort enormously.

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

yes
All i have said here regarding pure OpenGL and cross platform tiled
rendering, that's just my take. I don't want to argue about it, but rather
help in with the current plan.
Perhaps to do some actual help, i should begin with doing some easy hacks
on this front, just to get the taste of it.
Would be good if someone could give me something to actually do.

any ideas?

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


-- 

[image: appicon.png]



*Ptyl Dragon*

Twitter <http://www.twitter.com/cloudoninc> | LinkedIn
<http://www.linkedin.com/company/cloudon> | Facebook
<http://www.facebook.com/cloudoninc> | Blog <http://site.cloudon.com/blog>