Re: storing chart doc on load ?
On Sat, 2012-12-22 at 22:05 +, Michael Meeks wrote: Either way, our whole approach to loading and converting-to-native all embedded OLE2 streams for charts etc. on load always seemed to me to be extremely curious / slow ;-) but probably I mis-understood something quite profoundly: I always wanted to have some time to dig through that to see what could be safely deferred: It was a super quick hack done in an afternoon IIRC. We should in theory really be able to disable all that convert on load stuff completely and render the preview as is normal, but on ole object activation if there's no actual application registered to load them then have an attempt at loading it ourself. Like, disable it, load an example, double click on it and track down from where the error about not being able to handle it comes from and see what happens if we hack in ourselves as a fallback there and fix things up on that route. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: storing chart doc on load ?
Hey Michael, I was surprised to see some similar things happening with VBA streams on load (or at least things getting written out again). After a bit of thought, I assumed that one was so we could re-store the identical input in the output again if it was not changed: so we could round-trip features we didn't understand. Yes for VBA we are doing exactly that. However in this case it is different as we are using the ODF export filter to store the chart document. The bug reporter comfirmed that this just moves the delay to the opening of the sheet. I think this is preferred to doing that during loading for all sheets. That way Calc seems to be faster even if it is not. I suspect this has to do with the way we display chart documents. Presumably the same might be useful for OLE objects, but ... I wonder if it interacts with Tools-Options-Load/Save-Microsoft Office in some useful way. I think this is more related to how chart documents are integrated into Calc. While not being in the edit mode we actually display a rendered image which is normally somehow generated during export. I suspect they added the export to trigger a recalculation of the image. As the reporter mentions we are doing the same now but it seems to bedelayed until the point where we actually need the chart documents. Either way, our whole approach to loading and converting-to-native all embedded OLE2 streams for charts etc. on load always seemed to me to be extremely curious / slow ;-) but probably I mis-understood something quite profoundly: I always wanted to have some time to dig through that to see what could be safely deferred: clearly rendering WMF previews for embedded charts for as long as possible would help us on load - but being able to edit charts is rather useful too ;-) So IMHO the bigger problem is how chart2 is internally implemented. It is a big chunk of uno implementation layers over each other. At some point we need to fix the horrible performance problems that are related with the chart2 design. The bug document shows this very good when you try to scroll in one of the sheets with a chart document. I think at some point we need to find some time to step by step clean the chart2 code up and remove quite a bit of the unnecessary uno parts in it. And of course the rendering layer in chart2 is a nightmare and has quite a few platform specific bugs. All the best over Christmas etc. ! Nice Christmas to you too. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
storing chart doc on load ?
Hi Markus, I was intrigued by your comment in: commit bb97ecdbcc8d8dafd39e728b21bc68efee4eccbc Author: Markus Mohrhard markus.mohrh...@googlemail.com Date: Sat Dec 22 14:19:38 2012 +0100 storing the chart doc while loading is a bad idea, fdo#57530 There seems to be no obvious reason why we would need to store the chart doc during xls import. The chart test docs don't show any difference without this call. I was surprised to see some similar things happening with VBA streams on load (or at least things getting written out again). After a bit of thought, I assumed that one was so we could re-store the identical input in the output again if it was not changed: so we could round-trip features we didn't understand. Presumably the same might be useful for OLE objects, but ... I wonder if it interacts with Tools-Options-Load/Save-Microsoft Office in some useful way. Either way, our whole approach to loading and converting-to-native all embedded OLE2 streams for charts etc. on load always seemed to me to be extremely curious / slow ;-) but probably I mis-understood something quite profoundly: I always wanted to have some time to dig through that to see what could be safely deferred: clearly rendering WMF previews for embedded charts for as long as possible would help us on load - but being able to edit charts is rather useful too ;-) All the best over Christmas etc. ! Regards, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
