[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fenfire-dev] CLI
From: |
Matti Katila |
Subject: |
Re: [Fenfire-dev] CLI |
Date: |
Thu, 22 Jul 2004 09:00:57 +0300 (EEST) |
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