What about bounty? 3D acceleration bounty?


In near past we used such tool as bounty. Why we don’t use it today? Haiku inc. have enough money.
What we need right now? 3D accelleration and modern browser such as Chrome, Firefofox, etc…

Why not open bounty for 3D Acceleration? It’s will be good motivation for developers. Maybe Augustin or someone else not from Haiku can implement 3D accelleration.


Using the search function upper-right side would reveal plenty different threads about this specific idea, with all the pros and cons, why-s and why-nots, but TLDR:

Yeah, possible, but who would do it? Do not count on us, we already have plenty on our plate.

Recruitment could help there. So let’s solve that problem first.


I’d personally rather see funds going to Webpositive development. Firefox and chrome would be nice, but I prefer our native browser.

Also, 3D acceleration isn’t being ignored. It’s just on the back burner until R1. Remember that Haiku is still in Beta. The projects goal is to duplicate the functionality of a system that failed in part to a focus shift. Remember Be Inc, and their crazy BeIA project? Right now Haiku is focused on R1. I’m fairly certain that the devs have learned a thing or two about focus shifts, or this project wouldn’t even exist in the first place.


I don’t need funds to work on WebKit. I need more people helping me. For some reason there is close to zero interest for it, as if it was some “black magic - do not touch” code. I don’t know why. It’s just a plain application and there are a lot of easily implemented html5 features. Geolocation? Gamepad support? Fullscreen video replay? Just fixing crashes in my existing messy code (probably starting with video and websockets)?

Really, there are many tasks that can be fixed with a couple hours of work. I tend to leave these aside hoping someone else will have a look, but that strategy isn’t really working for now, it seems.


I said that in hopes that maybe funding would perhaps draw some help your way. Maybe my logic isn’t sound. I’d like to start putting some time in as well, but as with all our volunteers, time is a precious commodity.

One small task that’s been bugging me, that I’d like to fix myself as a primer into webpositive is a small error in the context menu when you right click on links. It gives just the option to open in new window, and it opens a new tab instead. I’ve grep’d all over the Webpositive source looking for the related code, but was unable to find it. If you could give me a direction to it, I’ll look into solving it. Thanks!



That’s where I was looking… Under the Webpositive tree.


This is actually managed directly in WebKit.
Relevant parts are probably https://github.com/haiku/webkit/blob/rebased/Source/WebKitLegacy/haiku/WebCoreSupport/FrameLoaderClientHaiku.cpp#L524 and https://github.com/haiku/webkit/blob/rebased/Source/WebKitLegacy/haiku/WebCoreSupport/ChromeClientHaiku.cpp#L130

The first file is where we take decisions for various actions such as navigations (clicking on a link), new window (from the “new window” menu), etc. The second is where we create new window and tabs.

On WebKit side there isn’t really a notion of a tab that I know of, so we have to cheat a bit to tell our native code wether a page should be opened in a new tab, or a new window.


Hey boy, take it easy. I’m with Haiku since r25xx. So don’t need to explain to me what is Haiku and how to cook it.
As I remember most of big parts of Haiku such as locale kit, package management, etc… were sponsored.

So why not create new bounties for needed projects? Such as 3d HW acceleration?
It would be new impulse for system and users. And maybe fresh blood for developers.


Because mixed experiences with GSoC the foundation should not advertise this bounty for newcomers, even if it contraproductive is.
The required changes dives way too deep, so one cannot just jump onto the moving train.
It needs planning, extensive research and etc.
I would say it is at least 2 years for implementing the basics, and that still doesnt mean anything visible… maybe.
Feel free to correct me.


I was a full time BeOS user back during the BeIA focus shift fiasco and was present in Columbus OH at WalterCon 2004 when Michael Phipps announced the name change from OpenBeOS to Haiku. Many of us remember the focus shift quite well and don’t want to see Haiku suffer the same fate. R1 is too near to lose focus now.

Shifts in focus are resource intensive. They put immense strain on any organization, whether it is a big company like Be Inc., or a small non-profit like Haiku.

As I recall, hardware acceleration was originally back in the day slated for Glass Elevator, the code name for OpenBeOS beyond R1. Patience, my friend. We’re gonna get there. Stay focused. :wink:


Locale Kit was part of the original BeOS API, so it needed to be implemented for Haiku R1. As I also recall, adding package management so soon was a huge point of contention (many viewed it as a focus shift, and needless delay to R1.) A modern package manager was not part of BeOS. It seems we lost some good devs over that fiasco, some of whom I remember fondly from the BeOS days. HaikuDepot put quite a delay on R1 already. There is no need to repeat that.

Hardware acceleration will likely be a big ticket focus as R1 gets released.


Adding hardware acceleration support shouldn’t really cause problems…

Package management could have been added in a way that didn’t cause problems but it wasn’t… so here we are still recovering from that. Even so I’d honestly like a mode of installation where packages are unpacked to disk fully… for lower end systems and or better compatibility.


True, but adding it a wrong way could make a big headache later or a real Frankeinstein.


It was not. BeOS was only available in english, and maybe a hard-translated japanese version?

There were a few 3rd party localization systems available, and one eventually made it to Zeta.

The implementation in Haiku is derived from the one in OpenTracker, but with a lot of rework and extensions. It is largely my own design, with input from other devs, mainly Oliver Tappe who mentored my GSoC project on this.

The year following that GSoC project I was paid directly by Haiku to continue that work. At that time, I was a student, so I had pleinty of time for that in the summer, and could do it on a low pay because my parents would cover my living costs already. This is not possible for me anymore.

The point is, in most cases Haiku could not afford to pay developers for such big projects. We have enough money to hire students, or well known developers who accept to work at the same low rate ($12.5 per hour in most past contracts).

At the moment we focus on GSoC (because the money does not come from us anyways) and this summer we’re planning to try sponsoring at least 1 student through Outreachy, which seems focused on quality more than quantity of applicants. We’ll see how that goes. There may be other partnerships involved (I’m currently discussing with my employer to see if they’d want to sponsor Oureachy students), we’ll see how that goes.

Anyway, I’m not sure a bounty is going to help unless:

  1. You have someone interested in working on something
  2. Their current situation does not allow them to spare enough time
  3. They are ready to leave their current situation for it
  4. They have the required skills and we can trust them to get some results

In my case, starting to do paid work for Haiku again would mean leaving my paid job, which earns a lot more and has other benefits (funding travel to conferences, working with other people and learning from them, and the safety of a fixed pay every month). This means working full-time for Haiku at this point would be unreasonable. So 3 is a problem for me.

For GSoC students and outsiders in general, we have to worry about 4. In GSoC, if it turns out not to work we just fail the student and they don’t get paid. But would someone take the risk of working on something without being sure they get paid for it? I certainly wouldn’t. I would do such things only in my free time besides a real job, and I’m already spending that time working on Haiku anyway.

So, if someone fullfills these 4 requirements, they should voice up and we’ll see what we can do about it :slight_smile:


The big problem I’d see with adding hardware acceleration at this point is the delay of R1. Hardware acceleration should remain in Glass Elevator status. Let’s reach a goal and quit moving the goal posts.


I really need work on my long term memory. Especially at lunch time.


Since R1 Beta branch has already been separated, hardware acceleration can’t delay R1 any further.


I still see it as potentially taking developer time away from R1. Which would be a delay. Unless we were attracting devs with a thorough knowledge of the Haiku inner workings, kernel etc. I don’t see that happening any time soon. There was a reason for Glass Elevator.


That apply to basically any part of Haiku. Like the media_kit there are lots of easy tasks like :

  • m3u support
  • fix encoding in ffmpeg
  • fix media preferences layout
  • rework SoundRecorder GUI

There should be some problem in the project?