Re: [Fenfire-dev] CLI

[Matti Katila]

On Thu, 22 Jul 2004, Benja Fallenstein wrote:
> Matti Katila wrote:
>>>Images are similar, but a bit harder because there is no nice ImageVob 
>>>that shows an image loaded from an arbitrary InputStream and that works 
>> try
>> make java rundemo DBG="-Dvob.api=awt" DEMO=org/fenfire/spanimages/spandemo.py
>> make java rundemo DBG="-Dvob.api=gl" DEMO=org/fenfire/spanimages/spandemo.py
>> in fenfire and type some ControlL keys or any other..
> 
> Now I'm wondering, would it be possible to separate image rendering from 
> Alph, so that it could move to Libvob?

I think that longer standing goal is to use storm and not some arbitrary 
input stream. At least with gl, the temporary images generated for 
textures are named like 
'vnd-storm-hash_-_image__png,pbqrtu42fqpm2zgceea7kzukwiaej5hi.6i 
kqbro4lk7yf6yrhlw6xutvcpc45u2qodebmzy-2048x2048'
so it wouldn't be wise to use a name like 'foo.png' because another  
'foo.png' is newer seen on screen. 

For arbitrary images it may be easier to use a hackery-plugin like:


pool = storm.impl.TransientPool(java.util.HashSet())
myalph = alph.impl.StormAlph(pool)

def getSomeArbitrarySpanImageVob(file):
    # should not try to guess the content type :/
    scrollblock = myalph.addFile(java.io.File(file)), 'image/png') 

    return ff.spanimages.SpanImageFactory.getDefaultInstance(). \
               f(scrollblock.getCurrent())

Most of image rendering is in libvob but because fenpdf shows pdfs and 
postscripts as images it needs storm for storing them. Also texture pool 
manager, which should be fixed to listen user input, that allocates 
texture space is in fenfire.


   -Matti