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