strayorange

When I released ImageTweak 0.19 I wrote in the changelog that the main change was the support for proper image drag&drop.

It actually works correctly but this change had the side effect of changing the normal mouse pointer used by ImageTweak to indicate that you’re moving an image around the window. I noticed this before releasing the update, but it seemed like a minor annoyance worth the additional functionality. I actually tried to fix it but found no way, and since there were a lot of people writing negative reviews on AMO for the lack of drag&drop support I decided to release it without fixing it.

Fast forward some weeks, and it turns out that actually the new behaviour is quite confusing and many are complaining about the mouse pointer showing the “forbidden” shape while moving the image. Fewer than they were complaining before about the lack of drag&drop, but still…

So I set out to find a solution for this problem but apparently there’s no way to freely control the mouse pointer shape during a drap&drop operation. The only thing that comes closer is setting the mozCursor property of the DOMDataTransfer interface to “default”, but that works only on win32 and simply switch the cursor from “forbidden” to the default arrow.

I’m therefore pretty much stuck in a fix: I have to fix this problem but I have no idea of how. If you know how to do this, or know somebody that might help me in fixing this, please let me know.

After a month or so in the AMO review queue, ImageTweak 0.19 is finally available. Current users should be notified of the update soon.

To learn what’s new in 0.19, read this post. To download the latest version please head over to AMO.

While waiting for the review process for the 0.19 update to end (apparently the queue is a few weeks long – damn you Mozilla) I got bored and decided to create the ImageTweak page on Facebook.

Go spread the word!

Having recently bought a netbook (MSI U123) I had to readjust my browsing habits since normally I work on a 24″ Dell 2407WFP with a resolution of 1920×1200, whereas the MSI has a meager 10.1″ at 1024×600.

As a result I had to tweak my browser of choice to be able to work nicely on such a small screen. Fortunately enough, Firefox allows you to tailor almost exactly as you want, and to reclaim much of the needed vertical screen space.

So, let’s get started. read more »

A few months and a complete change of location (I’m in Helsinki right now!) later, ImageTweak is going to reach version 0.19.

I had to scrape all the work I already did for 0.19 because I hit a few roadblocks, and so I had to start over with a minor but longstanding bug: proper drag&drop support. What it means is that you won’t have to hold CTRL anymore when performing drag&drop. The price is that I had to drop support for firefox 2.x and 3.0.x.

I just added it on AMO. As soon as it gets reviewed it will be available for download.

p.s. I also enabled donations on AMO, so if you feel like it please support the development of ImageTweak.

One of the most exciting upcoming features of HTML5 is the ability to open persistent bidirectional sockets to a remote host.

As far as I know, one of the early proposals was about allowing web applications almost complete control over sockets, including the ability to create raw sockets and to listen for incoming connections exactly like a typical network daemon/server, but this proposal was later scraped because of security implications.

Fast forward to today and the Web Sockets API, even if still under development, are starting to get a stable shape and they will probably be implemented soon by the most forward-looking browser vendors.

The problem is, though, that the original proposal got crampled along the way and therefore there won’t be any means to create peer-to-peer connections between users, something that could enable all kinds of cool distributed systems.

That is, unless someone does something: what I’m thinking about right now is a kind of wrapper/extension around the Web Sockets API that does simply a few things:

1. allows a web application to register for incoming connections
2. opens up the required ports on the firewall/NAT
3. when a connection arrives, perform the handshaking required by the ws:// protocol and forwards a WebSocket object representing the connection to the application

Talking IDL, that would mean (the WebSocket interface is the current WHATWG proposal, while WebSocketListener is my addition):

[Constructor(in DOMString url, optional in DOMString protocol)]
interface WebSocket {
  readonly attribute DOMString URL;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSED = 2;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long bufferedAmount;

  // networking
           attribute Function onopen;
           attribute Function onmessage;
           attribute Function onclose;
  boolean send(in DOMString data);
  void close();
};

[Constructor(optional in short port, optional in DOMString protocol)]
interface WebSocketListener {
  readonly attribute short port;

  // ready state
  const unsigned short OPENING = 0;
  const unsigned short LISTENING = 1;
  const unsigned short CLOSED = 2;
  readonly attribute unsigned short readyState;

  // networking
           attribute Function onconnection;
  void close();
};

Talking about the Mozilla platform, points 1 and 3 are straightforward (once the Web Sockets API has been implemented), whereas point 2 will be platform-dependent and, therefore, trickier. Nevertheless, I think that all of this can be handled (with some work) by a Firefox extension.

Once Firefox will gain Web Sockets support I’ll definitely try to see if it is possible to add it.

Yep, I finally managed to reach Helsinki after 10 days spent wandering about Europe by train… we’ve seen Mainz (Germany), Amsterdam (Netherlands), Copenaghen (Denmark) and Bergen (Norway).

From there I reached Stockholm and, by overnight ferry, Helsinki.

Right now I’m busy trying to arrange all the paperwork and finding some basic furniture for my room… I don’t even have a bed right now! (apparently Finns don’t provide beds in their student dormitories)

Lessons are bound to start in 5 days time, so I’ll need to have everything fixed by then. We’ll see.

Last week I wrote about my x264 patch that would enable B-frames heuristic decisions in x264.

Today I finally managed to do some proper testing using the Big Buck Bunny PNG image sequence from xiph.org, and found out that for reasonable settings (b-frames 8, b-heuristic 4) we have an overall 4% speed gain and for more extreme settings (b-frames 16, b-heuristic 4) we gain 17% overall.

The base command line used in this test is –b-adapt 2 –b-pyramid -r 4 –crf 26 -A all –direct auto -w -m 9 –psy-rd –mixed-refs -8 -t 2 –threads 3 –thread-input.

In the following pretty graph™ I plotted the frames-per-second for various settings (b-frames/b-heuristic):

The following are the raw results taken from the x264 logs:

I just put together a patch (it’s more of an ugly hack but whatever) that makes –b-adapt 2 somewhat faster.

Basically what it does is to adapt the number of b-frames to look for based upon the length of the previous consecutive b-frames span. It is way easier just to read the patch to find out how it works; this is the relevant part:

+    /* adaptive max b-frames */
+    if( h->sh.i_type == SLICE_TYPE_P )
+    {
+        int i_gop_bframes = h->fdec->i_frame - h->fref0[0]->i_frame - 1;
+        const int i_bframes_overhead = 4;
+        if ( i_gop_bframes + i_bframes_overhead > h->frames.i_adapt_bframes )
+            h->frames.i_adapt_bframes = i_gop_bframes + i_bframes_overhead;
+        else
+            h->frames.i_adapt_bframes--;
+        h->frames.i_adapt_bframes = x264_clip3( h->frames.i_adapt_bframes, 0, h->param.i_bframe );
+    }

i_gop_bframes is the length of the previous span of consecutive b-frames and i_bframes_overhead is an arbitrary constant (possibly to be parametrized).

h->frames.i_adapt_bframes is initialized (and reset at every scencut) to h->param.i_bframe (i.e. the number of b-frames specified on the command line).

The same adaptive method can be easily added also to –b-adapt 0 and 1, but I guess that it wouldn’t give the same speedup.

Right now I’m running a few tests and I will post further results briefly, but the first tests showed a speedup ranging from 5 to 30% (being heavily dependent of the content of the video) for -b 16 (I know that this is the best-case scenario as well as I know the tendancy of doom9ers to max out their settings ).

Just a few more warnings: I tested it only on a Ubuntu32 VM and I have not paid much attention to concurrency issues (there should be none, and I experienced no crashes or other misbehaviour – but I’ll wait for a review from the x264 devs about this). I tried to be as clear as possible in the patch, but I guess that at least a few variable names and comments will have to be edited… I couldn’t come out with better ones, though.

That’s all. Feel free to comment and give (possibly) constructive advice.

A few days ago I received my bachelor’s degree in engineeering.
Now, something everybody knows about me is that it looks like I kind of like being late… and this is what precisely happened on friday: a few members of my family and some friends of mine were there to watch me receiving my degree, but I actually was a couple kilometers away stuck in the traffic.
Guess you’ll have to wait for my master’s degree, guys…