Hi!
iPad3 even not in sale

Andrey

We may refrase the question to: Is it possible with multiresolution html5 360 viewers ?

I doubt.

Depends on your target audience and your client (if he is willing to pay). Alsoo if you cant sell Ipad compatible tours, then the client can look for someone that can. If you are concerned about the future, html5 is only going to be bigger and wider supported (desktops and other mobile devices) while the future of flash is a bit uncertain (although cool stuff is coming like the new Stage3d which will give much better rendering)

multiresolution is mainly an memory issue. Handheld devices are known for their low memory/lower speed compared to desktop to save on battery consumption. There are rumors that ipad 3 will have a massive resolution. If they dont up the memory and cpu, then tours will even run heavier then now (more resolution = bigger image to make up for artifacts = more power needed).

Yes, probably Klaus could enabled iPad multiresolution with a variable change but doesn't want to handle all the support requests about it crashing.
Now with distorted hotspot support, I don't know why the hotspots can't be added/removed on demand or why someone hasn't already wrote a couple of functions to do this already.
Perhaps the memory still isn't released with removeplugin or it would be REALLY jerky if you are adding removing plugins this way.. or perhaps you can populate a plugin matrix and set them to a 1px png when they are out of sight.
Though, if this would work, then I don't know why it wouldn't work with the basic multiresolution setup without the need for all these hotspots.

I guess the problem lies in the way a multiresolution-pano works. When the pano-player switch to a new resolution step there needs to be both steps in the memory, at least for the loading and blending-time. And that's where the low memory of the Idevices would become a problem in a lot of cases. Don't forget that it's not just the resolution of a pano that eats a lot of ram, but also the motive. An image with a lot of details and/or gradients results in a LOT bigger filesize. And like Sacha already said, the forum will be flooded with crash-reports from krpano-amateurs if Klaus enables multires-support on iDevices. So I really hope he wont And a krpano-professional could use already invented techniques to simulate multi-resolution on the iPad!

Best regards
Nupsi

Zitat von »Nupsi«

I guess the problem lies in the way a multiresolution-pano works. When the pano-player switch to a new resolution step there needs to be both steps in the memory, at least for the loading and blending-time. And that's where the low memory of the Idevices would become a problem in a lot of cases. Don't forget that it's not just the resolution of a pano that eats a lot of ram, but also the motive. An image with a lot of details and/or gradients results in a LOT bigger filesize. And like Sacha already said, the forum will be flooded with crash-reports from krpano-amateurs if Klaus enables multires-support on iDevices. So I really hope he wont And a krpano-professional could use already invented techniques to simulate multi-resolution on the iPad!

Best regards
Nupsi

That is just not true. What the viewer has to work with is not the compressed size but the actual file size. If it is more or less compressed does not matter.

I think a lot of people does not know that HTML5 panos requires much more memory than flash. At least thats what you see if you load the same panorama in Safari and change between Flash display and HTML5.
The HTMl5 actually uses double as much memory and especially at loading this can easy be close to the the 250 mb that the iPad 1 has.

The iPad Safari browser is however much better to handle this than the desktop browser.
In my activity Monitor I can see that the actual memory use for a standard iPad 1024x1024 cubeface pano increases from 60-70 mb for flash to 125mb for HTML5.
During loading the HTMl5 uses up to 180mb while the flash pano only uses 90.

Note that this is not including the basic memory that Safari uses.

Hans