It might be a problem with your video driver maybe not allowing WebGL to
use GPU acceleration. I'd think the vendor's docs about the driver would
say. I supposed it's also possible you need to update the driver - in
case they enabled GPU acceleration support in a newer version.
Of course, if I recall correctly, Microsoft considers any kind of GL
graphics "alien ware" and would much rather have applications use
DirectX instead. At least it did in the many years back that I used Windows!
On 07/15/2012 05:47 AM, Nate wrote:
Yep I'm running on Windows. I wonder what the problem could be? Its a
shame because I think its great that panoramas (all graphical web apps
for that matter) can be developed without needing to rely on bulky
proprietary software.
On Saturday, July 14, 2012 9:37:29 PM UTC+1, GnomeNomad wrote:
I believe that WebGL's ability to use GPU acceleration is dependent on
the video driver and OS platform involved. IIRC, WebGL on Linux only
uses GPU acceleration with a few proprietary (binary) drivers. WebGL's
use of GPUs is much more available on Windows.
Of course, if you're running Windows on your laptop, none of that
helps.
On 07/13/2012 03:17 PM, Nate wrote:
> Hey Alex,
>
> Thanks for making your code available. I had a look at it and I am
> impressed. I imagine it is very efficient because, as you said,
it maps
> the correct texture pixel data to the viewport. I assume this
means the
> texture pixel data that is not in the viewport is not being
> unnecessarily rendered. I can't as yet fully understand the GLSL
code
> (reading up on it is on my to-do list) so I can't be too sure of
what
> I'm looking at. So it has left me wondering why the frame rate is
quite
> jumpy on my laptop when compared to the flash panorama
implementation.
> Can webGL not take advantage of GPU acceleration?
>
> Thanks again,
> -Nate
>
> On Tuesday, May 29, 2012 1:11:34 PM UTC+1, Axel wrote:
>
> Hi Matthew,
>
> I like your initiative to do something about the state of the
> available web panorama viewers. If it weren't for those poor IE
users,
> it would be dead obvious, that WebGL is the way to go (and I have a
> tendency trying to ignore those whenever I can ;)). I did some
> experiments regarding WebGL and panorama viewing myself some time
ago:
>
> http://lizardq.com/posts/experimental-webgl-panorama-viewer/
<http://lizardq.com/posts/experimental-webgl-panorama-viewer/>
> <http://lizardq.com/posts/experimental-webgl-panorama-viewer/
<http://lizardq.com/posts/experimental-webgl-panorama-viewer/>>
>
> Although, my focus was primarily on getting some HDR panorama
viewing
> feature onto our website.
>
> You seemed to be interested in a low a footprint script. I have
about
> 400 lines of js and another 120 GLSL code (but admittedly using
jquery
> for convenience). The geometrical approach I used is different:
there
> is no textured 3D structure approximating a sphere and then
looking at
> it from the inside. I render a simple viewport sized quad and use a
> fragment shader to find the proper pixel position in the source
> texture for each pixel in the viewport.
>
> You or anyone who is interested should be able to get a look at the
> (uncompressed) code if you know your browser web debugging
facilities.
> If you think replacing tree.js with some GLSL code might be
> interesting, let me know.
>
> - Axel
--
Gnome Nomad
[email protected]
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/
--
You received this message because you are subscribed to the Google Groups "Hugin and
other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
