Re: [DotGNU]PDF DOT GNU

[Gopal V]

If memory serves me right, Rhys Weatherley wrote:
> This is why our interpreter sometimes outperforms JIT's - it spends more time 
> executing and less time converting.  I suspect that a PDF viewer written in 
> C# that parses to a tree form and then displays immediately would actually 
> outperform "compile PDF to IL first".

This IMHO is kinda like 

pdfObj=PDF.LoadPdf("mine.pdf",PDFOptions.Compiled);
pdfObj.SaveTo("mine.pdf.dll");
fastPdf=PDF.LoadCompiled("mine.pdf.dll");
fastPdf.Show()

As long as all the PDF instructions can be converted to IL , it's possible.
In fact it'll be portable as well :-)

> P.S. I'd love to see a PDF viewer written in C# using Qt# or Gtk# for the 
>      GUI. That would be cool.

Btw, Rachel Hestilow has confirmed that Gtk# doesn't use too much of 
System.ComponentModel for working ... So since I'm able to run some of
the examples with pnet CVS , I assume that it's working ... The PInvoke
marshalling is the only remaining problem with my hack at PtrToStructure
failing for structs with no default constructor ...

It's a major change for the PInvoke marshalling to move from the native mode
to using the ILCoder API. (this might slow down pnet a bit , but not too 
much).

And I've been thinking about pnet and the unroller API ... if all the
unrolled instructions used registers for parameter or stack top transfer,
would it speed up operation ? ... [considering the fact that most unrolled
instructions just use the topmost 2 elements of the stack, this becomes
relevant ?]

Of course , we have more important things to worry about before speed...
See meeting announce for today's agenda..

Gopal
-- 
The difference between insanity and genius is measured by success