But why don't you pick a 4+GB flash drive and install the newest version of <your favourite distro> on it and enable the unstable stuff? Then you can easily test things out without any damage to your work machine.
(You most probably have a machine which you can boot from a pendrive.)
Just my 2 cents.
having a secont thought about the ray scanning the scenery - its rubbish! you would have to take the average of a certain area.. so it would rather be recursively with a recursion every time your broad ray hits an object partially or totally (or totally but transparent) to add all the colours found in the ray.
probably the simple approach would be a total overkill.... cant you just pass a property to an object - like a matrix? do it will turn over time? like flux matrices? and update them eventually? i may simply not know where the graphics card sets in... i thought the scenery is being placed on the graphics cards video memory, created by the CPU - so you could just give very primitive instructions from CPU to gpu like: turn object A or increase intensity of light source B.
i guess that thats what unigine and stuff are into... i still wonder why there are so many approches...
dang... id really like to get into these things... just that i need to do something for a living... if it would pay the rent id do it next to my studies...
back to webGL. is webgl what creates the obects out of a websites content?
umm... sorry for the mess...
It seems to me that easily end-user runnable test frameworks that make it easy to reproduce bugs as well as capture debugging information on what's going on at the time of the bug - not just for WebGL but for all APIs - would go a LONG ways towards improving the state of open source video drivers.
I have been absolutely plagued by stability and video corruption issues on a number of different video cars - admittedly mostly ATI / radeon.
If I had a an easy way to reproduce these issues and report USEFUL information about these issues back to the developers, this would improve the user experience not only for me, but for everyone else using similar hardware.
Issues I've had:
1. Lack of developer interest - not sure if this is because of poorly written bug reports (I tend to report my bugs upstream first w/Fedora) or lack of developer resources.
2. Developers instructing me to compile stuff from source as it might be fixed in the latest before seriously looking at the report - unfortunately this is difficult to do and instructions on how to do so are sparse.
The codepaths in modern, large software stacks are essentially untestable. It's always possible that software which has been working rock solidly for a decade will crash and burn the second someone else comes along and tries something just ever so slightly different than what everyone before them tried.
does everyone write his own graphics commands or what is webGL now? i mean i'm a stupid physicist, and i really wonder what its all about.
It's exposing a lot of bugs because browsers need to create multiple contexts; one for each tab/window. Almost every other OpenGL application out there creates a single context and a single window. Turned out the code in Mesa is broken when dealing with multiple contexts in a single process. Mozilla found and exposed that bug in code which nobody had ever really stress-tested before.
Without 3D hardware, that's slow as shit. Take a look at some of the Google Chrome Experiments WebGL pages. There are some impressive demos in there that can't even pull 60 FPS on my NVIDIA GTX 460m with the proprietary drivers. Imagine how completely non-functional those would be in a software implementation.Quote:
want to turn an object? write matrix!
want to move object? write matrix!
(And yes, there are valid industry uses for WebGL, particularly in visualization and gaming.)
There is no other approach. WebGL is the only standard way to access 3D rendering in a browser.Quote:
or is it so important to have different approaches for different needs?
I noticed that Mesa/DRI2 was crashing, and discovered that the patch in this bug report fixed it.
Crash in dri2_invalidate_drawable
Sure is nice running a single command and having the entire system updated to bleeding edge. And you know what, I've had far fewer stability issues on Arch than I had with Ubuntu, Fedora, etc.