Blogs

WebKit weekly report #2

Blog post by PulkoMandy on Fri, 2013-10-04 06:26

It's Friday again !

So, in my last blog post I told you I was converting our WebKit build files to CMake. This week I managed to get a working HaikuLauncher (the test browser that comes in the WebKit tree) and surf the web a bit with it.

Jack2 : A Personal Analysis (Part #2)

Blog post by Barrett on Mon, 2013-09-30 16:28

Hello, it has been passed some time from the Part 1 of this article, I've continued my investigations as well, and I have finally some more clear plans for such a hypotetic Jack2 port. Unfortunately i had not enough time to research a bit more in the latency differences between the media_kit and jack, sorry, this should be post-poned until i have precise emphyrical measuring methods.

To better understand this article i suggest you to read the first part.

The Wrapper

So, after lots of temptations, a night i decided to take the jack API headers and begin to stubb a jack wrapper.

This gave me the possiblity to explore in a better way the internals of Jack2.

The result of this work-night, is the jack_simple_client seamless working. Don't misunderstand me, the code is just a proof-of-concept, actually the backend media_node support only producers hooks, and have some problems such as the sound hear a bit streched. Other than being funny, this project has permitted me to understand better how the BMediaNode class work. I would like to synthetically make a resume of the work,

it consists of three layers :

  1. C-API bindings to c++ internal classes
  2. Jack2 emulation which is composed of two classes at the moment, JackPort and JackClient.
  3. JackNode, a native media_kit node controlled by the emulation layer, which serves as the gate between the Jack emulation and the media_kit.

This is a map of the functions on which i worked and their status :

E = empty
P = partially implemented
OK = fully implemented / sufficient implementation ATM.

jack_activate OK
jack_client_close OK
jack_client_name_size OK
jack_client_open OK
jack_connect P
jack_deactivate P
 
jack_get_buffer_size OK
jack_get_client_name OK
jack_get_ports P
jack_get_sample_rate OK
 
jack_midi_clear_buffer E
jack_midi_event_get E
jack_midi_event_write E
jack_midi_get_event_count E
 
jack_port_get_buffer P
jack_port_name OK
jack_port_register P
jack_port_type_get_buffer_size OK
 
(the original implementation is mantained)
jack_ringbuffer_create OK
jack_ringbuffer_free OK 
jack_ringbuffer_mlock OK 
jack_ringbuffer_read OK
jack_ringbuffer_read_space OK
jack_ringbuffer_write OK
jack_ringbuffer_write_space OK
 
jack_session_event_free E
jack_session_reply E
 
jack_set_buffer_size_callback OK
jack_set_process_callback OK
jack_set_session_callback E
jack_shutdown E
 
jack_transport_query E

You can see the code here.

Intrinsic Limitations

There are some intrinsic limitations due to different designs, which might be a bit complicated to deceive.

  • Jack2 support multiple connections to one port.

    There's not a lot to do about it, the only solution without explicit support from the media_kit is to map one jack port into multiple input (or outputs). For example, in Haiku a stereo output is a unique port, you can't connect two mono channels to a stereo one without using a mixer node, in Jack2 instead stereo channels are separated by default.

    Anyway i do think a feature to separate stereo channels should be taken into consideration for a future media_kit version.
    **EDIT** To be more clear all implementations of JACK permit connections between ports with any valence, they can be 1:1, N:1 or 1:N.

  • Jack2 support glitch-free ports reconnection.

    Well, as far as i know the media_kit just is unaware of this concept.

    **EDIT** In those hours, emerged that it relates only a jack2 implementation detail of
    the API, so it will be a limitation for a native port but not for libjackcompat. That's a good news indeed.

  • Jack2 features a session API which is simply missing in Haiku.

    This is something already discussed in the mailing list, basically other than being a low-priority part of the API, it could be just emulated until Haiku features a session management system, which will probably come out after R1.

The Jack port and the wrapper

I discovered that there is not need of an external app routing audio between jack2 and the media_server.

With the premise that the incompatibilities in libjackcompat and the issues i explained in the last article are still valid, since the jack_ports management is done by the driver i think an Haiku driver could work that way :

  1. When a jack client is registered a media_node is created, for every port there will be a input/output in the node.
  2. When a media_node is created, it will be mapped into a jack_client, and every i/o mapped onto a jack_port.
  3. The phantom clients will be internally managed to work as audio streams mirrors.
  4. By default there will be a media_node wrapping the jack system_mixer into the Haiku's one.

But i would like to show you an use case where it may be complicated to create an efficient and transparent strategy :

Imagine the jack_client1:port1 is connected to jack_client2:port2. jack_client2 is a media_node in the back-end, so it will wrap the port2 into a native input.
So, now imagine a new jack client, called foo_client, what happens if it try to connect to jack_client2:port2? In jack it's completely legal, but in the media_kit there will be only a input, and no way to make a double connection.

As you may understand, this is a headache. To my mind comes only two different solutions :

  1. Make the behaviour somewhat configurable in settings and in the media_node settings panel. So that you can for example map two jack ports into one media_kit stereo connection.
  2. Force users to use appropriate mixer nodes between connections.

So, What's The Need for a wrapper?

Except the fact that with some degree various simple apps should work out of the box, i think a wrapper is still important for a lot of reasons, if it will work for basic functionalities, it could be used by third-party developers as a initial layer to base their native Haiku port.

For example, as start you can compile your jack2 program, then you include the wrapper into your source tree and begin to modify it to fit your needs.

The last but not less important thing is that the libjackcompat backend will provide most of the functionality needed to create the backend-nodes, so it may be possible that a media_kit jack2 driver will be based itself on this library.

As before, i just tried to explain my vision, hope it was interesting...as ever
any opinion, question and correction is appreciated!

Package Management Goes Live

Blog post by bonefish on Fri, 2013-09-27 22:33

I'm proud to announce that, at last, the package management branch has been merged into the main development line, aka master branch. The builds and nightly images from hrev46113 on will include the new feature.

WebKit weekly report #1

Blog post by PulkoMandy on Fri, 2013-09-27 08:56

Hey, it's Friday already !

So, now that I'm (mostly) done moving and I have set up my workplace (including internet access, electricity, and everything required), I can finally start doing some actual work on WebKit. So, what's hapenned this week ? Well, actually, not that much.

A quick reminder, you can follow the commits on the bnetapi branch of haiku-webkit repo at github.

I've also set up a Gist TODO list so you can see things I want to work on. Please send me comments about websites that don't work well, I'll add them to the list and see what can be done.

Results: S&T Evaluation and Web Survey

Blog post by czeidler on Tue, 2013-09-24 00:27

Most work on my PhD thesis is done and I like to provide you with the results from our research at Uni Auckland on Stack & Tile. At BeGeistert 023 (October 2010) I conducted a user evaluation of Stack & Tile to answer the question whether stacking and tiling within an overlapping window manager bring any benefits to the user. At the end of last year I used a web survey to investigate if and how Stack & Tile is used by actual users. The results of both studies have been presented recently at the INTERACT'13 conference in Cape Town. INTERACT is an A ranked conference for Human Computer Interaction (HCI) and hopefully I was able to interest some other researchers in Haiku. Thanks again for all participants of the evaluation and the survey!

The encouraging results are summarized in the following. The complete paper can be found here.

Stack & Tile Evaluation (BeGeistert 023)

We investigated the benefits of Stack & Tile's stacking and tiling features in a traditional overlapping window manager. Therefore we looked at use-cases where the user is working with documents of the same or of different applications, and a use-case where data is exchanged between documents of the same application, and designed experimental tasks accordingly. Another task measured the time needed to switch between different groups of windows.

In a controlled experiment, we found that stacking and tiling features can significantly improve completion times for tasks involving several windows (of the same application as well as of different applications). Furthermore, switching between different tasks was found to be much faster when windows were grouped by task using Stack & Tile. Setting up a Stack & Tile group is an initial overhead that may prevent users from using these features. However, the potential time savings as well as questionnaire answers indicate that the advantages outweigh this overhead.

Stack & Tile Web Survey

Stack & Tile is already integrated into Haiku for over two years, and thus is already exposed to a large group of developers and users. This allowed us to target another interesting question: How are stacking and tiling features used and accepted by real users? In a web-based survey we asked the Haiku community about their opinions and experiences of Stack & Tile. From 146 responses we got a detailed insight into how, how often and for what applications Stack & Tile is used.

There was a wide agreement that Stack & Tile can be useful, especially by participants who had used Stack & Tile before the survey. The stacking feature was perceived as being slightly more useful and also estimated to be used more than the tiling feature. We found that people were using the stacking and tiling features for a multitude of different use-cases, e.g., programming, browsing or file management. In a field for general comments many people wrote that they like Stack & Tile and suggested further ideas to integrate it more into the desktop. These ideas include future works such as grouping of windows by their Stack & Tile group in the taskbar and Stack & Tile group persistence.

More news from WebPositive

Blog post by PulkoMandy on Thu, 2013-09-12 17:03

Hi everyone,
It's been two weeks since the previous blog post, so here goes an update.

First of all, I wanted to make it clear that I haven't started to work on my contract, so the few things that happened in the last two weeks were done on my free time. Said free time was short, as I'm in the process of moving to another city and I've been packing a lot of stuff and cleaning my flat. Note I will be offline starting next week, and I hope to get internet access back as soon as possible. I won't start working on the contract before I'm back online, as testing a web browser without any internet access creates more problems than I'm willing to solve.

Enhancing the scheduler

Blog post by Paweł Dziepak on Sat, 2013-09-07 20:17

Soon I am going to work as a full-time Haiku developer on enhancing the scheduler. The goal is to improve performance of the whole system and finally deal with some long standing problems. To achieve this CPU affinity will be introduced what would make cache utilization better and I will implement scheduler strategies based on dynamic priorities what, hopefully, would once and for all deal with priority inversion. In addition to that, I want to make scheduler more power-aware. Haiku currently lacks low-level support for some of the more advanced power related features of CPUs but having scheduler ready for would save us from redesigning it later. Also, there are still ways to conserve energy without using the most recent technologies.

Syndicate content