Hi;
On Mon, 2008-09-29 at 13:04 -0700, ere wer wrote:
>
> Hi, Matthew,
> test-textures crashes with message box:
>
> Microsoft Visual C++ Runtime Library
> Runtime error!
> Program: ...
> abnormal program termination
>
> When crashed it was at 6500 and ate about 500MB ram (I have 4gb, so its not a
> system ram problem; my video is gF8800GT 512ram)
>
> I cannot create backtrace because gdb hangs until the program is force-quit
> from the taskmanager.
>
Without a backtrace there is little I can say / advise. It looks like
its hitting the limits of your cards texture memory so maybe there is an
issue there with the driver - I really dont know.
>
> Anyway, please answer my other questions.
>
> Is it possible to know the max image size?
>
> Will texture have (drastically) different limits on different computers?
>
> Is not "sliced" supposed to work around "the gpu limitations", or it helps
> only with the video cards`s max size of a single texture limit, not the video
> ram limit... as far as I remember (from my limited d3d exp) there should be
> an option to store the tex in system memory, although it will be slow.
>
Right, 'slicing' is there to work around any image size limits.
> Overall how reliable texture is for (many?) normal-large images? Looking to
> some cool "interactive desktop" toy apps with many spread digital photos, I
> wonder if Clutter could handle this by itself, or it must relay on some heavy
> coding to pass only images within some limits for it to render.
>
Clutter currently does no texture 'proxying' in swapping/caching images
in/out of texture memory to disk. Its not too hard however to implement
this for a specific use case. Making it very general is quite hard.
=== Matthew
--
Matthew Allum, Intel Open Source Technology Center
--
To unsubscribe send a mail to [EMAIL PROTECTED]
