Re: LiMux student "kick-off"

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

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

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

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

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

> 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@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@collabora.com  <><, Pseudo Engineer, itinerant idiot
>
>
>
> --
>
>
>
>
> Ptyl Dragon
>
> Twitter | LinkedIn | Facebook | Blog
>
>
>
>
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice