Is it only on my computer so?
Over an year ago, the Haiku3D demo showing an HAIKU with the HAIKU coloring and texture, where every letter rotates one after another.
Later the texture was lost. All letters are gray and rotates.
Last I have tried out hrev 51985 and the letters of the demo are still gray.
Is it only on my computer so or is it an well known bug?
It isn’t an important program, but it comes with Haiku itself. So I think, it should be working ok.
Greetings
theuserbl
We upgraded MESA library last year I think and it has some rendering problem. We should probably downgrade it to a working version.
Please re-provide the Mesa swrast driver. The swrast driver fixes the problem.
They are not gray here. I get the usual leaf colors (no textures, but I don’t recall ever seeing textures in this demo?)
Test the current x86_64 nightly image and run Haiku3d. The leaf colors are grey like the ‘Haiku’ lettering. This differs from the same rendering with the current x86 nightly image. If you swap the x86_64 Mesa swpipe driver for the legacy x86_64 Mesa swrast driver, this fixes the problem along with other rendering issues. Tested on Haiku x86_64 with Mesa 17.1/18.0/18.1 libraries.
Providing the legacy x86_64 Mesa swrast driver in x86_64 nightly images and Haiku Depot repo allows users to ‘fallback’ to the swrast driver since there is an issue with Mesa ‘swpipe’ driver (until the x86_64 ‘swpipe’ driver gets fixed).
Ah right, of course I don’t get this issue on a gcc2 system.
It would be great if people at haikuports did more testing than “it compiles” before updating core software…
And this type of thing is exactly why there needs to be more oversight over what happens between developers. If no one developer cares how their changes affect the OS or another developer’s work, this kinda thing will keep happening.
The bottom line is: no change(s) made should ever break other apps or the functionality of the OS.
How to do this? Have developers TEST their changes before commiting them. It cannot be expected that all possible outcomes can be tested, but at least test the case your change was intended to improve, first. If your change could affect both x86 AND x64 Haiku, then TEST both environments. If it can ONLY affect x86, then test just that environment. But, at least CARE enough to test.
This is easier said than done, unfortunately. Testing every possible case would take a lot of time, indeed.
The problem is not that much on Haiku side, actually. The Haiku project always had high standards as to what gets included, and the devs are generally careful about what they do (breakage do happen occasionally, unfortunately). The situation even improved with Gerrit, as we now have an area where we can store work-in-progress code and benefit from peer review on it.
Where we are getting more problems currently is on HaikuPorts side. HaikuPorts has adopted a much more open policy (anyone can submit pull request on github), and while they do perform review to ensure submitted recipes look and work fine, they tend to do little testing of the results.
This is understandable as the project has started to gain traction only quite recently, and does not have the same culture as Haiku - after all, they never made a release of any kind there.
Currently, the Haiku package repos are populated straight from haikuports master branch, which means such problems land directly into the user systems. This is not acceptable by Haiku standard, and it is one of the last few things we need to solve before we get a beta out. Either by having haikuports improving their testing requirements before they merge things, or by somehow creating a “stable” packet repository for our releases.