When a multires image AND a mobile image is defined, then the viewer chooses the multires ones by default (when multires is supported).Why is that not enough. Why do I need to also filter out all the image levels.?
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 |
<image multires="true" ... devices="!ios">
<level ...>
...
</level>
...
</image>
<image ... devices="ios">
<cube ... />
</image>
|
The hardwarelimit was a setting for the old non-multires engine and limits there the maximum size of a single/merged cube face. In multires the sizes or number of the levels don't matter, there will only a few tiles from each level be loaded - the ones that are necessary for the current view - that means the viewer wouldn't load 'all files from level 4'.And why is not the hardwarelimit="1024" working? That would be a perfect way to control the memory usage for the panorama.
Its very obvious that it is when you load all the tiles for the 4th level and then need to unload them that you get the crashes
Benutzerinformationen überspringen
Wohnort: Netherlands
Beruf: Krpano custom coding / Virtual Tours / Photography / Musician / Recording engineer
: https://pame.virtualtuur.comAfter testing the multi resolution on my iPad 3 for a month I give up.
It is not worth it. There are too many crashes.
It may work with simple panoramas without any hotspots, videos, sound or popups but for a tour like this one
http://virtualdenmark.dk/dnm/kina/ it does not work. I have tested it with standard 1024 cubefaces without any problems. No crashes at all.
However the multi resolution crashes at least 4-5 times during a full session of the tour.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »HansNyb« (24. November 2013, 16:09)
Right, automatic reloading during autorotate on mobiles/tablet is just not ready at the moment.aren't loading further image tiles in autorotation mode. this occurs only on tablets ... about this in the
missing/planned feature list of the 1.17 html5 viewer ... or ask
klaus wether it's perhaps just not ready.
I agree, this is also a topic I'm working on.I think the textfield options really need to be updated.
That's not fully correct - in almost all realtime computer graphics one pixel typically need 32bit = 4 byte of memory (RGBA with 8bit per channel). The reasons therefore are memory addressing, compositing and just easier usage. That means six 1024x1024 images need at least 24 MB of memory (=4 x 6 x 1024 x 1024). And in real it can be probably much more, e.g. one copy of the image in the CPU ram and one copy in the GPU ram.Actually a standard mobile size 1024 pixel cubefaces pano only uses 18mb.