<div dir="ltr">inline<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 8:17 PM, Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ptyl,<br>
<span><br>
On Wed, 2014-09-17 at 15:45 +0300, Ptyl Dragon wrote:<br>
> ok, then we'll use GL2.1. we'll make sure we use only API used in ES 2<br>
> too.<br>
<br>
</span>        The whole situation around different GL versions vs. mismatching GLES<br>
versions etc. is too horrible for words =) my hope is that we could<br>
support OpenGL 3.2 - to get a good Mac baseline, and fallback for Linux<br>
where we can.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> We need simple thing. after all, we are not making a First Person<br>
> Shooter. For starters we are just making a 2d rendering engine<br>
<br>
</span>        =)<br>
<span><br>
> I don't think i follow. Is the idea is to keep using the current<br>
> rendering mechanism, and just use OpenGL to render lines and<br>
> rectangles?<br>
><br>
</span>        I guess that's a good first start.<br>
<span>><br>
> in any case, for tiled rendering, we want to render all the elements<br>
> in the tile together and at once, per tile. If this is all done by<br>
> OpenGL, it would ensure the performance we require.<br>
<br>
</span>        Sure - doesn't that follow from a pure OpenGL renderer ?<br></blockquote><div><br></div><div>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 mechanism....though 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.    </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> Also note that in tiled rendering, notions like copyArea are<br>
> irrelevant, as by definition, each tile contains nothing of the<br>
> neighboring tiles.<br>
<br>
</span>        The copyArea stuff is interesting; my hope is that we could get rid of<br>
that mess; however that intersects with some of the paint / timer work<br>
that is also planned for the interns - since we currently defer<br>
re-painting of various things to a timeout.<br></blockquote><br></div><div class="gmail_quote">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".<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
<br>
> 1. what exactly is the thing that is already working on desktop?<br>
> (explanation + code pointers)<br>
<br>
</span>        We have some nice cross-platform GL context creation going on that<br>
Markus created I believe (sadly he is away from a PC / E-mail from now)<br>
- which should be easy to re-use.<br></blockquote><div><br>great! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> 2. what are VCL plugins? Does VCL have a plugin infrastructure ? does<br>
> it use dynamic linking (if so, it won't work for iOS)? it would be<br>
> great if someone could direct me to some code pointers that show how<br>
> this plugin infrastructure works<br>
<br>
</span>        The backends have the vcl/inc/ API including salgdi there to implement;<br>
but on Linux we can choose dynamically between many of these backends<br>
eg. KDE3, KDE4, GTK2, GTK3, raw-X etc.<br></blockquote><div><br></div><div>got it <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> 3. I'm not sure if i saw the OpenGL development plan, so i'd be happy<br>
> if anyone could direct me to it.<br>
<br>
</span>        I've just forwarded you some rough notes.<br></blockquote><div><br></div><div>thanks.<br></div><div>i looked at them. Possibly, i will need a hands on review of it, to know where CloudOn / myself can bulge in.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> I want to learn all there is to learn, so to be able to actively<br>
> expedite this front (i.e hack the way myself)<br>
<br>
</span>        Sure - so I think one thing we need to get unwound (and that you<br>
identified and raised) is the issue of immediate rendering.<br>
<br>
        If we go for immediate rendering; then we need to render to an<br>
off-screen frame-buffer, and then we can fool around with copyArea<br>
etc. ;-) [ this is not such a terrible thing to do of course but not<br>
ideal ]. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
        If we instead collect damage from immediate rendering, and then just<br>
trigger a full re-render of that area using an OpenGL context - then<br>
that might work better: and overlap with tiled rendering.<br>
<br>
        In the end / long-run we'd want to rid ourselves of immediate<br>
rendering, and emit damage events not in window co-ordinates but<br>
document co-ordinates (IMHO etc.). But of course - as a first step<br>
killing all immediate rendering is a great idea.<br></blockquote><div><br></div><div>as i mentioned above, possibly the immediate rendering can be considered as a special case of non immediate rendering, via a tiled rendering mechanism for all platforms. possibly this will take us forward faster, though we'd be skipping over a few milestones in this fashion, which is kind of a dangerous waterfall.<br><br></div><div>Still, again, if we get it working on Android, we could incrementally add it to other desktop OSes, while still seeing "progress in the wild".<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
        Chris Sherlock was having a look at this problem in the past - with an<br>
aim of stopping Windows deriving from OutputDevice - such that it's not<br>
even possible to go rendering on Windows in an un-controlled way at any<br>
time.<br></blockquote><div><br></div><div>again, i think the solution should be to move to tiled rendering on all platforms. But then again, moving all platforms to tiled rendering, raises the effort enormously. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
        It would be great - Noel - perhaps this is something you could do ? =)<br>
if we could find all instances of method calls on OutputDevice that<br>
occur in a method that is not a child of some 'Paint' or render<br>
method ;-) [ that would give us a hit-list ] - I'm not sure if that is<br>
Clang-plugin-able ? ;-) [ how is the view of the call-graph from there<br>
].<br>
<br>
        Ideally all rendering is done to a transient context that is passed in<br>
only for the duration of the rendering call.<br>
<span><br>
> As Markus is now on vacation, perhaps someone else can help me with<br>
> these issues? I don't want to stall a month now, as I believe we can<br>
> make progress in this time frame<br>
<br>
</span>        Does any of the above help ?<br></blockquote><div><br></div><div>yes<br></div><div>All i have said here regarding pure OpenGL and cross platform tiled rendering, that's just my take. I don't want to argue about it, but rather help in with the current plan.<br></div><div>Perhaps to do some actual help, i should begin with doing some easy hacks on this front, just to get the taste of it.<br></div><div>Would be good if someone could give me something to actually do.<br><br></div><div>any ideas? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> If it will make things simple, efficient, and maintainable, then all<br>
> good with me, again, i'm an OpenGL noob, and i don't know where the<br>
> performance bottlenecks are Still, to prevent a waterfall scenario,<br>
> let's wait with the gradient handling, and the drawing layer<br>
> optimizations in general, until we have things working in VCL without<br>
> it.<br>
><br>
</span>        Personally, I'm completely with you on: "First make something work" ;-)<br>
then we can go for performance - but it'd be great to avoid making big<br>
design / performance mistakes at the outset of course/ </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
        Hope that helps,<br>
<br>
        All the best,<br>
<div><div><br>
                Michael.<br>
<br>
--<br>
 <a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>  <><, Pseudo Engineer, itinerant idiot<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><br><table style="font-family:arial;font-size:small" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="width:51pt;padding:0.75pt" width="68"><pre style="font-family:"Droid Sans Mono","Lucida Console","Andale Mono","Courier New",Courier,monospace;font-size:12px;line-height:12px;color:rgb(0,0,0)"><img alt="appicon.png" src="http://site.cloudon.com/wp-content/uploads/2012/05/appicon.png" style="line-height:normal;color:rgb(34,34,34);font-family:Helvetica,sans-serif;font-size:9pt" height="63" width="64"><br></pre>
                                </td>
                                <td>
                                         </td>
                                <td style="width:207pt;padding:0.75pt" width="276">
                                        <p style="margin-right:0.4pt;margin-bottom:0.0001pt;margin-left:0.4pt">
                                                <b>Ptyl Dragon</b><br>
                                                <br>
                                                <a href="http://www.twitter.com/cloudoninc" style="color:rgb(17,85,204)" target="_blank"><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(148,201,71);text-decoration:none">Twitter</span></a><span style="font-size:11.5pt;font-family:Helvetica,sans-serif"> </span><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(102,102,102)">|</span><span style="font-size:11.5pt;font-family:Helvetica,sans-serif"> </span><a href="http://www.linkedin.com/company/cloudon" style="color:rgb(17,85,204)" target="_blank"><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(148,201,71);text-decoration:none">LinkedIn</span></a><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(102,102,102)"> |</span><span style="font-size:11.5pt;font-family:Helvetica,sans-serif"> </span><a href="http://www.facebook.com/cloudoninc" style="color:rgb(17,85,204)" target="_blank"><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(148,201,71);text-decoration:none">Facebook</span></a><span style="font-size:11.5pt;font-family:Helvetica,sans-serif"> </span><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(102,102,102)">|</span><span style="font-size:11.5pt;font-family:Helvetica,sans-serif"> </span><a href="http://site.cloudon.com/blog" style="color:rgb(17,85,204)" target="_blank"><span style="font-size:10pt;font-family:Helvetica,sans-serif;color:rgb(148,201,71);text-decoration:none">Blog</span></a></p>
                                </td>
                        </tr>
                </tbody>
        </table>
        <table border="0" cellpadding="0" cellspacing="0">
                <tbody>
                        <tr>
                                <td style="width:51pt;padding:0.75pt" width="68">
                                         </td>
                                <td style="width:207pt;padding:0.75pt" width="276">
                                        <p style="margin:0in 0.4pt 0.0001pt">
                                                 </p>
                                </td>
                        </tr>
                </tbody>
        </table>
</div>
<br></div>
</div></div>