On 06/06/12 16:54, Michael Stahl wrote:
> On 06/06/12 15:31, Stephan Bergmann wrote:
>> On 06/06/2012 03:11 PM, Tor Lillqvist wrote:
I would go the UNO approach nevertheless.
>>>
>>> It's a hard decision to make...
>>
>> With the current state of touch/idl, what you would want to do in C++ is
On Wed, Jun 06, 2012 at 06:42:44PM +0100, Michael Meeks wrote:
> Hi guys,
>
> On Wed, 2012-06-06 at 16:33 +0100, Iain Billett wrote:
> > I haven't experimented but I've heard that not using power-of-two
> > lengths is seriously detrimental to performance.
>
> Must make a mental note to ask
http://stackoverflow.com/questions/4593951/can-we-use-non-power-of-2-textures-on-opengl-es-on-android
So apparently if one uses OpenGL ES 2.0, there is NPOT support. Not
necessarily in OpenGL ES 1.0 (might be present on some devices as an
extension). But do we want to use OpenGL ES 2.0, I can't re
Hi guys,
On Wed, 2012-06-06 at 16:33 +0100, Iain Billett wrote:
> I haven't experimented but I've heard that not using power-of-two
> lengths is seriously detrimental to performance.
Must make a mental note to ask a GPU hacker; in fact - lets do that :-)
Luc - sorry to bother you with a q
>> Sure, but on the other hand it makes it simpler in that we don't need
>> to figure out the aspect ratio of each page (they can be different)
>> beforehand.
>
> Surely we have to do that in order to present it to the user ?
Yes, but no. There is something of a chicken-and-egg problem here
> IMHO the use of the term 'tiles' here is prolly just a misleading
> nonsense ;-) my main concern is the ability to render an arbitrary
> sub-set of a page to an arbitrarily sized texture.
That is exactly what I have in mind, too;)
--tml
___
LibreOffic
On Wed, 2012-06-06 at 17:48 +0300, Tor Lillqvist wrote:
> >IMHO the decision to render just squares prolly complicates the
> > situation un-necessarily.
>
> Sure, but on the other hand it makes it simpler in that we don't need
> to figure out the aspect ratio of each page (they can be dif
>
> >IMHO the decision to render just squares prolly complicates the
> > situation un-necessarily.
>
> Sure, but on the other hand it makes it simpler in that we don't need
> to figure out the aspect ratio of each page (they can be different)
> beforehand.
>
> BTW, I didn't mention in the I
On 06/06/12 15:31, Stephan Bergmann wrote:
> On 06/06/2012 03:11 PM, Tor Lillqvist wrote:
>>> I would go the UNO approach nevertheless.
>>
>> It's a hard decision to make...
>
> With the current state of touch/idl, what you would want to do in C++ is
> an implementation of the Document service, p
> IMHO the decision to render just squares prolly complicates the
> situation un-necessarily.
Sure, but on the other hand it makes it simpler in that we don't need
to figure out the aspect ratio of each page (they can be different)
beforehand.
BTW, I didn't mention in the IDL, but I did th
On Wed, 2012-06-06 at 16:16 +0300, Tor Lillqvist wrote:
> >It'd be rather nice to have some parameter names rather than just
> > 'long' 'int' etc. etc ;-)
>
> Of course. Those are specified in the IDL. No Java source code is
Ah - sorry pardon; I read the IDL in the directory:
+
On 06/06/2012 03:11 PM, Tor Lillqvist wrote:
I would go the UNO approach nevertheless.
It's a hard decision to make...
With the current state of touch/idl, what you would want to do in C++ is
an implementation of the Document service, plus potentially an
implementation of an XDocumentRender
> It'd be rather nice to have some parameter names rather than just
> 'long' 'int' etc. etc ;-)
Of course. Those are specified in the IDL. No Java source code is
generated from IDL, it generates class files directly (well, through
.rdb), and there are no parameter names in class files. The
> I see no need for a DocumentRenderCallback service.
OK, I didn't realize that you can have an interface without wrapping
it in a service.
> I would go the UNO approach nevertheless.
It's a hard decision to make...
--tml
___
LibreOffice mailing list
Hi Tor,
On Wed, 2012-06-06 at 14:43 +0300, Tor Lillqvist wrote:
> OK, so I did some design of how an API to render (tiles of) pages
> would look like that could be used both on Android and iOS apps.
:-)
> public interface org.libreoffice.touch.XDocument extends
> com.sun.star.uno.XInterf
On 06/06/2012 01:43 PM, Tor Lillqvist wrote:
Now I am having second thoughts, though, but still, a first, in
progress, draft API is in UNOIDL form is in touch/idl.
I see no need for a DocumentRenderCallback service.
XDocumentRenderCallback will be implemented by UNO objects specific to
the va
OK, so I did some design of how an API to render (tiles of) pages
would look like that could be used both on Android and iOS apps.
My first idea was to do it based on UNO. On Android the Java code
would then call the implementation in the "normal" nice way one from
Java code calls UNO services. Fo
17 matches
Mail list logo
