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