LiMux student "kick-off"

[Ptyl Dragon]

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

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.

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


-- 

[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/cfea4af4/attachment.html>