LiMux student "kick-off"

Wed Sep 17 05:45:42 PDT 2014

hi Markus
hope you enjoy your vacation
and thanks for the feedback

inline

On Wed, Sep 17, 2014 at 2:58 PM, Markus Mohrhard <
markus.mohrhard at googlemail.com> wrote:

> Hey,
>
> So I will only be able to provide a short feedback as I'm still on
> vacation for another month and don't have access to any computer.
>
> On Sep 17, 2014 9:29 PM, "Ptyl Dragon" <ptyl at cloudon.com> wrote:
> >
> > This week we (CloudOn) did a kick off for the openGL project,
> > mainly reviewing OpenGL, and what we know of the requirements for the
> project.
> >
> > My conclusions so far (feel free to correct them. i'm an OpenGL noob):
> >
> > 1. We should use OpenGL 3.0 ES API - i.e use the 3.0 ES API subset, even
> when using non OpenGL ES (e.g on linux, osx, windows)
>
> That is way too young. Currently I think we should target Opengl 2.1 and
> keep an option for OpenGL 3.2 open. That would mean we would target
> something along of OpenGL ES 2.0. I can't check right now the differences
> between the es version and the normal opengl version.
>
ok, then we'll use GL2.1. we'll make sure we use only API used in ES 2 too.
We need simple thing. after all, we are not making a First Person Shooter.
For starters we are just making a 2d rendering engine

> > 2. Use cases:
> >
> >      a. Tiled rendering (i.e mobile) -
> >
> >          i. OpenGL renders to a memory buffer. It would be best if the
> tile memory would have been this memory buffer, but if not, then this
> memory buffer is later copied to the tile OpenGL context.
> >          ii. Context creation is handled by the Mobile app
> >          iii. this is the simple case
> >
> >     b. Window (i.e Desktop) -
> >
> >         i. LibreOffice's SalInstance should create an OpenGL window, and
> provide the openGL context (enabling the option can be denoted via a
> compilation flag). This needs to be done per OS, though possibly, can be
> simplified via abstraction frameworks such as SDL, or what have you.
> Possibly, this task is a good candidate for mentoring
>
> We have that already. The OpenGLContext class abstracts the creation of a
> context. We can't use an existing framework as it needs to integrate with
> vcl at least on the desktop.
>
good to know
>

> >         ii. the rendering is done via 3 buffers: 2 buffers (front and
> back) for de-interlacing, and 1 back layer buffer for actual rendering.
> Additionally, for stuff like copy area, we might require temp buffers for
> bit blit, and resending these bitmaps back to the GPU. Would be happy to
> find a better solution, as it sounds like copying the same bitmap 4 times...
>
> At least on the desktop this is not true. We have automatic front and back
> buffer. I know that this is a bit more complicated on mobile platforms but
> even then I think you only need 2 FBO. The place where you want a FBO for
> copy operations textures seem like the better idea.
>

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?

>
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.
Also note that in tiled rendering, notions like copyArea are irrelevant, as
by definition, each tile contains nothing of the neighboring tiles.

> >         iii. this is the complex case, and as such, arguably, we should
> begin the work on tiled rendering, then apply the solution on the window /
> Desktop case, in a later iteration.
>
> I totally disagree here. The desktop stuff is already working and it is
> only some work necessary to create a new vcl plugin. I would prefer if we
> start there as this can easily be tested by many people and the development
> plan is already available (see the estimation that Michael shared with
> you). For the tiled rendering we first need to work on some infrastructure
> problems that are not yet fully understood.
>
I would like to understand the details of what you just said:
1. what exactly is the thing that is already working on desktop?
(explanation + code pointers)
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
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 want to learn all there is to learn, so to be able to actively expedite
this front (i.e hack the way myself)

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

> >
> > 3. Shaders - For simplicity and performance (i.e to not compile shaders
> again and again), we should use one costant naive Vertex shader all the
> time, and one constant Fragment shader, which uses if statements to
> differentiate between 2 states - solid color, and texture. AFAIK, VCL does
> not use any other more complex rendering. Note also, that if statements in
> GLSL are optimized on the GPU, so using them should not cost performance.
>
> That sounds just wrong. You only need to compile your shaders once if you
> correctly manage the life cycle of them. We most likely only need one
> vertex shader bit should use a few different fragment shaders. Especially
> to handle some more complex features like gradients efficiently. One of the
> ideas of creating an OpenGL context was that we could move some of these
> ugly tasks like drawing gradients to the GPU.
>

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.

As i said above
Considering all you have just mentioned, i think i need far better
understanding of the current status.
I need more visibility as for what was done, what is currently done, and
what needs to be done, not just in general terms, but with actual code
references, so that i could too start hacking.

As you said, you are now on vacation, so perhaps someone else could

>
> > 4. Text - would be rendered using the current software implementation,
> and rendered via openGL, as bitmaps.
> >
> > Considering these, action items are (VERY roughly):
> >
> > A. add build flags if necessary
> > B. decide whether to approach tiled rendering first. If so, solve
> context creation on mobile apps. If not, implement the OpenGL context
> creation for SalInstances on all OSes
> > C. Write the shader
> > D. Replace the VCL primitive drawing functions one by one, with OpenGL
> counterparts
> > E. Handle the copy area case
> > F. Handle the Bitmap case
> > G. Handle the text case
> >
> > if agreed upon, we could distribute the action items, and begin the
> actual work
> >
> > On Wed, Sep 17, 2014 at 1:10 PM, Michael Meeks <
> michael.meeks at collabora.com> wrote:
> >>
> >>
> >> On Wed, 2014-09-17 at 11:47 +0200, Jan-Marek Glogowski wrote:
> >> > AFAIK Miklos was Michaels suggestion for the mentoring - can't
> remember.
> >>
> >>         Matus is the XFastParser expert =) I guess it'd be nice to have
> a small
> >> XFastParser unit test as well (as some sort of entry-level easy-hack
> >> there).
> >>
> >> > Probably we should simply add a Wiki page for easier coordination?
> >>
> >>         Sure - why not =)
> >>
> >> > Comments please
> >>
> >>         All sounds sensible, my hope is that we can mentor
> interactively and
> >> superimpose the two-weekly "what got done" meetings =)
> >>
> >>         Anyhow - exciting tasks !
> >>
> >>         ATB,
> >>
> >>                 Michael.
> >>
> >> --
> >>  michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot
> >>
> >
> >
> >
> > --
> >
> >
> >
> >
> > Ptyl Dragon
> >
> > Twitter | LinkedIn | Facebook | Blog
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > LibreOffice mailing list
> > LibreOffice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
> >
>
>

-- 

[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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20140917/172de74e/attachment.html>