Re: LiMux student kick-off
On Wed, 2014-09-24 at 14:18 +0200, Florian Haftmann wrote: From a bird's-eye perspective, this would IMHOP consist of the following tasks: The current matter of affairs is now documented in the Wiki. https://wiki.documentfoundation.org/Development/LHM_LiMux#Priority_Main_Loop To be continued… Florian -- PGP available: http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
since the LiMux students are already working on various LO EasyHacks, I really want to get the long-term projects started. We're using currently using the #libreoffice-lhm channel for communication. I hope the respective groups get organized themself. And I hope I have all involved persons in the CC. And here is an initial wiki page for our benefit: https://wiki.documentfoundation.org/Development/LHM_LiMux Florian -- PGP available: http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
Hi Florian, On Wed, 2014-09-24 at 14:18 +0200, Florian Haftmann wrote: From a bird's-eye perspective, this would IMHOP consist of the following tasks: I love your breakdown =) * Identify the hot-sport where events are announced. Sure - so, this is a matter of looking for finding / documenting all 'Timer' sub-classes. * Formally extend this interface with a priority parameter with not-yet a meaning. Sure - so, what I'd do is create a 'Idle' class - initially derived from Timer (I guess), and start to add a series of #defines or similar to give each an integer priority [ leaving some nice spaces ]. Then inside the Timer class map that back to the ~awful '35ms is low priority' '50ms is after that' etc. ;-) Of course, -some- things we may actually want to do inside a timer - eg. blinking the cursor =) for this we really want a 'TimerSeconds' sub-class that moves the timeouts to a second boundary: this is important for reducing power-use: so the CPU wakes up once per second sharp on the transition, and does as much work as possible before going back to sleep =) [ we're missing that concept sadly - for now just stub / wrap that ]. Our cursor should blink either once-per-second or every half-second I think to get the benefit there. Having done that I hope we are back where we started - but we have a nice series of priorities for these various things. Any comments or hints? Otherwise I guess the first item is the one to start with. I think we missed some unit tests =) it'd be great to create some of these too particularly for Timers - which we've just re-worked on Windows to make them might higher resolution. Personally, I'd do the API work as described above first - then take a long hard look at it =) before starting to work on the implementations of prioritized idle handlers in the backends. Of course - we can detect if the backend can do the priority foo (should be easy for glib users eg.) and if not use the fall-back 'orrible hard-coded times. Perhaps that gives a good, incremental path to go so commits can go to master, and we can keep everything working ? Anyhow - thanks for the investigation, a good plan; HTH, Michael. -- michael.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
Hi all, * VCL: main-loop / timeout foo [ menTor ;-] + Making our main-loop have an 'idle' concept with priorities vs. mix match timers. + Tobias Madl + Jennifer Liebel LHM: Florian Haftmann this issue did not raise much attention so far in this thread, so I'll try to excite some… From a bird's-eye perspective, this would IMHOP consist of the following tasks: * Identify the hot-sport where events are announced. * Formally extend this interface with a priority parameter with not-yet a meaning. * Refine the event data structure to interpret priorities accordingly. * Classify all existing event sources with desired priorities. * Adjust priorities accordingly. Any comments or hints? Otherwise I guess the first item is the one to start with. All the best, Florian -- PGP available: http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
Hi everybody, which GLSL version should be used? The existing shaders in chart2/opengl/ use the version 1.50. The shaders in canvas/opengl use version 1.20. Cheers Michael Tobias tobias_m...@web.de schrieb am 13:58 Freitag, 19.September 2014: At the moment i'm trying to get the unoxml/test/domtest.cxx (Bug 39625) working. So we'll see if it's usefull :) Cheers Tobi Am 19.09.2014 08:47, schrieb Matúš Kukan: On Wed, 2014-09-17 at 11:10 +0100, Michael Meeks 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). There is one in sax/qa/cppunit/parser.cxx - but needs more love. I've added simple css::xml::sax::XFastTokenHandler implementation in 6503be5311716cf520cf534ca1bb0fd595b93d72 What I think should be done there: 1, We need a better, more complicated input :-) 2, Extend DummyTokenHandler to recognize some of the element/attribute strings used in the input. 3, Implement simple XFastDocumentHandler and use setFastDocumentHandler() examples for this: - oox/source/crypto/DocumentDecryption.cxx - but we want to use tokens, not compare strings - unoxml/test/domtest.cxx - we don't build this, maybe we should, no idea how obsolete it is http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1xml_1_1sax_1_1XFastParser.html contains some description and there is also a link to a wiki with rather useful information. Best, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
On Wed, 2014-09-17 at 11:10 +0100, Michael Meeks 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). There is one in sax/qa/cppunit/parser.cxx - but needs more love. I've added simple css::xml::sax::XFastTokenHandler implementation in 6503be5311716cf520cf534ca1bb0fd595b93d72 What I think should be done there: 1, We need a better, more complicated input :-) 2, Extend DummyTokenHandler to recognize some of the element/attribute strings used in the input. 3, Implement simple XFastDocumentHandler and use setFastDocumentHandler() examples for this: - oox/source/crypto/DocumentDecryption.cxx - but we want to use tokens, not compare strings - unoxml/test/domtest.cxx - we don't build this, maybe we should, no idea how obsolete it is http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1xml_1_1sax_1_1XFastParser.html contains some description and there is also a link to a wiki with rather useful information. Best, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
At the moment i'm trying to get the unoxml/test/domtest.cxx (Bug 39625 https://bugs.freedesktop.org/show_bug.cgi?id=39625) working. So we'll see if it's usefull :) Cheers Tobi Am 19.09.2014 08:47, schrieb Matúš Kukan: On Wed, 2014-09-17 at 11:10 +0100, Michael Meeks 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). There is one in sax/qa/cppunit/parser.cxx - but needs more love. I've added simple css::xml::sax::XFastTokenHandler implementation in 6503be5311716cf520cf534ca1bb0fd595b93d72 What I think should be done there: 1, We need a better, more complicated input :-) 2, Extend DummyTokenHandler to recognize some of the element/attribute strings used in the input. 3, Implement simple XFastDocumentHandler and use setFastDocumentHandler() examples for this: - oox/source/crypto/DocumentDecryption.cxx - but we want to use tokens, not compare strings - unoxml/test/domtest.cxx - we don't build this, maybe we should, no idea how obsolete it is http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1xml_1_1sax_1_1XFastParser.html contains some description and there is also a link to a wiki with rather useful information. Best, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
On 17/09/14 13:45, Ptyl Dragon wrote: 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 Just bear in mind, iirc you can't get hardware 2d rendering any more. I seem to remember, from quite a while back too, that all modern video cards render 3d by default, and 2d is now a software layer on top. So basically, what I'm saying is don't choose 2d over 3d because you think it will be faster/more efficient. Because actually, it's the other way round. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
On Sep 18, 2014 8:42 PM, Wols Lists antli...@youngman.org.uk wrote: On 17/09/14 13:45, Ptyl Dragon wrote: 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 Just bear in mind, iirc you can't get hardware 2d rendering any more. I seem to remember, from quite a while back too, that all modern video cards render 3d by default, and 2d is now a software layer on top. So basically, what I'm saying is don't choose 2d over 3d because you think it will be faster/more efficient. Because actually, it's the other way round. That is not true at least not in the sense that we are going to US 2D rendering. 2D rendering is just a special case of 3D rendering in out case and fully hardware accelerated. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
Hi Ptyl, On Wed, 2014-09-17 at 21:08 +0300, Ptyl Dragon wrote: 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 ... 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. Sounds sensible; there is a nice list of things to avoid here: chart2/opengl/README.deprecated. FWIW - I got some insight from Markus via some low bandwidth / Australian out-back telegraph which is perhaps helpful =) He says: Sadly OpenGL ES is not a pure subset of normal OpenGL, at least of the versions that we target, so we need to make sure in both directions that the used features are available on both the OpenGL target version as well as in the OpenGL ES target version. Extensions can be used conditionally but core features are a bigger problem there. Actually I hope this is mostly a non-issue if we develop and debug this on a rich-platform rather than Android. Hopefully that way we only have to check we're not using things not available in GLES as you suggest. To elaborate on that point - IMHO once we have the stack efficiently rendering to GL from VCL through drawinglayer etc. on the PC then it is ~trivial to adapt this to tiled-rendering; it's just a different context / frame-buffer-object to render a part of the same scene to. So - why develop for PC first not Android ? well Android is the Devil's Armpit of a development environment. It is extraordinarily hard, and unreliable to debug native code there - the development iteration is not 'compile,run' but 'compile,zip,sign,hope-up-load-works,run' with the middle phases being not only slow but also un-reliable ;-) And that is before we get to the horrible issues of trying to debug broken OpenGL shaders etc. which is bad enough in a well maintained development environment ;-) nevermind on a remote machine with a confused GPU ;-) Of course we'll still have to audit / port that work to Android (which should be easy) after we're done but ... when it works the set of bugs to nail should be mercifully smaller I hope. 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 mechanismthough i guess that's a waterfall in itself. I'd like to avoid that really; lets have the fewest moving parts at once - we may discover on desktop hardware that (if we can render much faster) there is no real need for tiling for desktop performance - though its always nice to be power efficient of course. 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. For ease of development / debugging - it makes a huge amount of sense to develop this, at least initially on a PC platform I think. 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. Yep - it's a longer term thing; but I quite like the idea of binning immediate rendering via some just collect damage and re-render model =) it is IMHO a premature optimization on modern hardware. 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. Heh =) I'll fwd some ideas Kendy sent out - that is assuming you have a Linux VM somewhere with GL ? (would be useful to have anyway) ATB, Michael. -- michael.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
This could be a pretty big minefield on Windows. Look at Chrome and Firefox. They had to introduce ANGLE to do dynamic OpenGL-Direct3D translation, because there were too many OpenGL bugs and quirks, especially with Intel GPUs. Not to mention, that drivers installed from Windows update have often limited OpenGL support and not everyone installs drivers directly from GPU vendors. And yet they still have to use a driver/HW blacklist. I guess LO can get away with much simpler implementation, so it will not be as bad, but it's still something to consider. On Thu, Sep 18, 2014 at 3:25 PM, Michael Meeks michael.me...@collabora.com wrote: Hi Ptyl, On Wed, 2014-09-17 at 21:08 +0300, Ptyl Dragon wrote: 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 ... 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. Sounds sensible; there is a nice list of things to avoid here: chart2/opengl/README.deprecated. FWIW - I got some insight from Markus via some low bandwidth / Australian out-back telegraph which is perhaps helpful =) He says: Sadly OpenGL ES is not a pure subset of normal OpenGL, at least of the versions that we target, so we need to make sure in both directions that the used features are available on both the OpenGL target version as well as in the OpenGL ES target version. Extensions can be used conditionally but core features are a bigger problem there. Actually I hope this is mostly a non-issue if we develop and debug this on a rich-platform rather than Android. Hopefully that way we only have to check we're not using things not available in GLES as you suggest. To elaborate on that point - IMHO once we have the stack efficiently rendering to GL from VCL through drawinglayer etc. on the PC then it is ~trivial to adapt this to tiled-rendering; it's just a different context / frame-buffer-object to render a part of the same scene to. So - why develop for PC first not Android ? well Android is the Devil's Armpit of a development environment. It is extraordinarily hard, and unreliable to debug native code there - the development iteration is not 'compile,run' but 'compile,zip,sign,hope-up-load-works,run' with the middle phases being not only slow but also un-reliable ;-) And that is before we get to the horrible issues of trying to debug broken OpenGL shaders etc. which is bad enough in a well maintained development environment ;-) nevermind on a remote machine with a confused GPU ;-) Of course we'll still have to audit / port that work to Android (which should be easy) after we're done but ... when it works the set of bugs to nail should be mercifully smaller I hope. 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 mechanismthough i guess that's a waterfall in itself. I'd like to avoid that really; lets have the fewest moving parts at once - we may discover on desktop hardware that (if we can render much faster) there is no real need for tiling for desktop performance - though its always nice to be power efficient of course. 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. For ease of development / debugging - it makes a huge amount of sense to develop this, at least initially on a PC platform I think. 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. Yep - it's a longer term thing; but I quite like the idea of binning immediate rendering via some just collect damage and re-render model =) it is IMHO a premature optimization on modern hardware. 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. Heh =) I'll fwd some ideas Kendy sent out - that is assuming you have a Linux VM somewhere with GL ? (would be useful to have anyway) ATB, Michael. -- michael.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list
LiMux student kick-off
Hi everybody, since the LiMux students are already working on various LO EasyHacks, I really want to get the long-term projects started. We're using currently using the #libreoffice-lhm channel for communication. I hope the respective groups get organized themself. And I hope I have all involved persons in the CC. So - just as a reminder from the LOConf14 hack night: * KDE5 - OpenGL / VCL rendering backend (Moggi / Tor) + solve the BitmapEx problem ... + CloudOn / KDE5 / Android ? + DTardon ? + Stefan Weiberg + Michael Juamannn ** Tor - help with infrastructure / setup etc. LHM: Jan-Marek Glogowski I just started to refresh my 10+ year old OpenGL knowledge. * VCL: main-loop / timeout foo [ menTor ;-] + Making our main-loop have an 'idle' concept with priorities vs. mix match timers. + Tobias Madl + Jennifer Liebel LHM: Florian Haftmann * Import performance - XFastParser vs. old-style parsers. + ooxml foo [!] ... - semi-mechanical ? * Auto-correction first: + Daniel Sikeler LHM: Ignaz forster AFAIK Miklos was Michaels suggestion for the mentoring - can't remember. Last week at LiMux we sat together and wrote down aprocedure to handle the mentoring from our POV. We already have a non-digital kanban board (anybody used to https://trello.com/?). Sketch of a model for cooperation and coordination -- ### Framework * Two-week iterations (»sprints«) * At the transition from one iteration to another, there is a common status meeting via Google Hangout. This covers: * A status report concerning the passed iteration. * General remarks concerning the state of the whole progress, including refinement proposals. * A planning of the next iteration with envisaged aims and effort estimation as far as appropriate. * The iterations cover the following issues * Three major topics (»stories«): * OpenGL backend * Priority scheduling * FastParser promotion * Vast minor topics (»small tasks«): * easy hacks and most annyoing bugs from LibreOffice * various LHM-specific issues * Issues are selected via status meetings. A reasonable proportion of issues (e.g. 70 % stories, 30 % small tasks) is taken into account. * A task lifecycle could look like as follows * stories * iterative breakdown in smaller issues * overall status estimation (»_ % done«) * small tasks * qualification * development * test (four-eye-principle) * internal documentation (for LHM reporting) * Visualisation is done using a taskboard (Kanban like) * no equipment for digital taskbaord available, but we can take a photo for each status meeting * suitable color code, e.g. * story = green card * story task = bright yellow card * small task = pink card * Administrative tasks can also be represented (e.g. dark yellow card) * e.g. pre-qualification of LHM-specific issues * Structure of task board resembles task lifecycle ### Common Todos * Refinement of sketch * Agree upon sketch * Find suitable weekday for status report Probably we should simply add a Wiki page for easier coordination? Comments please Jan-Marek ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
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.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
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.me...@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.me...@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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 p...@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.me...@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,
Re: LiMux student kick-off
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. 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 ? 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. 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. 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. 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. 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. 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. 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 ? 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.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LiMux student kick-off
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.mohrh...@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 p...@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
Re: LiMux student kick-off
inline On Wed, Sep 17, 2014 at 8:17 PM, Michael Meeks michael.me...@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 mechanismthough 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 ].
