fidzu : freedesktop

Here are the slides at least. They are of course missing the fullscreen demos.

Cairo: 2D in a 3D World

30 Jul 2010 7:42pm GMT

Last week I've been in Brazil at 11th International Free Software Forum (FISL) talking about Linux Graphics for Small Devices*. I tried to cover a bit of everything that I learned in the world I've been immersed in some near past - I guess there aren't many news for freedesktopers though. Anyway, everyone is very welcome to give any kind of feedback and comment on it. Just follow here.

*actually, two nights in Porto Alegre and two nights in Curitiba. Was great to see most of my friends!

30 Jul 2010 4:38pm GMT

You can share files on your N900 via Bluetooth, E-Mail and web services (Flickr and Facebook) thanks to libsharing-dialog. But there is no file transfers to a contact through instant messaging.

The sharing dialog with Bluetooth, E-Mail and web services features

But look, the sharing dialog is obviously missing a fourth button named "Share via IM"!

Jonny Lamb wrote Monorail, a file transfer application for the N900. Monorail is a standalone application using the Telepathy framework but so far it does not integrate with libsharing-dialog. Libsharing-dialog is supposed to be extensible by plugins (see the Sharing Plug-in documentation). Unfortunately the API is more suitable for web services than for file transfers through instant messenging so it makes the work more difficult.

So I implemented that fourth button with some hacks to workaround the limitations of the libsharing-dialog API:

• The Monorail package dpkg-diverts libsharingdialog.so into /var/lib/funsharing/
• Monorail implements a new library (aka libfunsharing) replacing libsharingdialog.so with the same ABI
• Libfunsharing calls dlopen() on the real libsharingdialog.so
• It also patches the class GtkTable in memory (see struct GObjectClass->constructed) just before calling the real function from libsharingdialog.so, and restore it after the call. I use this hack to get a reference to the GtkDialog and the GtkTable containing the three buttons (the libsharing-dialog API does not give us any reference to these objects)
• In the constructed function of GtkTable, it adds a 4th button "Share via IM" which sends the filenames to share via D-Bus to Monorail
• Monorail receives the filenames from libfunsharing via D-Bus, shows the contact selector and send the files as usual.

The sharing dialog after installing Monorail 0.3

It works fine in the file manager and the image viewer. Do you know any other application with a file sharing feature?

The address book can share contact cards via SMS, Bluetooth and E-Mail but it does not use libsharing-dialog, so Monorail does not automatically add my "Share via IM" button.

Send a contact card from the address book

But since PR1.2, the address book has a new plugin API and it automatically links to your plugins installed in /usr/lib/osso-addressbook/plugins. The plugin API is designed for menu extensions and does not have helper functions for the sharing dialog. But with Marco's help, I replaced OssoABookSendContactsDialog's constructed function to add the fourth button:

Send a contact card from the address book after installing Monorail 0.3

Monorail 0.3 is available in maemo extras-devel.

30 Jul 2010 12:47pm GMT

I wrote a new script to launch a gdm login screen when a Plugable Docking Station is attached on the machine. To use this script, I reduced the number of ConsoleKit display.d, session.d and seat.d files. Now there is only one of each kind of file. The current version of my work is hosted at my git repository. To test it just follow the same tutorial of the last post and then attach a Dock Station on the machine. A gdm login should appear at the monitor.

30 Jul 2010 5:50am GMT

Even if I recently stated I lost some of my faith in XCB, I still sometimes hack things to add support for it.

These last days, I've worked on a D-Bus port from Xlib to XCB. The port was quite straight forward, since there's only a little piece of D-Bus using X, which is dbus-launch.

I though D-Bus was a good candidate, since it's part of the Freedesktop initiative. Therefore, I was expecting a warm welcome and some enthusiasm from a fellow project.

My contribution got one useful review, and a cold reply from Thiago Macieira (a KDE/Qt/Nokia developer):

No, sorry, I don't agree.. I've just checked and my Solaris machine doesn't have XCB. Please do not remove the X11 code. You may add the XCB code, but you cannot remove the X11 code.

This is not really the kind of answer I expected, actually. I then reworked the code to please Thiago, and added some #ifdef to add XCB support to D-Bus, with a fallback to libx11 where XCB would not be available.

Havoc Pennington replied:

Given that libX11 now uses xcb as backend, I don't understand the value of porting to use libxcb directly when there isn't an issue of round trips or other stuff. It will just make #ifdef hell, while the X11 API is an API that works on both xcb and non-xcb platforms. Maybe people should be thinking about porting xcb to non-Linux platforms? The X protocol should be the same on other UNiX, so xcb in theory ought to work fine if you just compiled it on Solaris/BSD, same as GTK or dbus or Qt would work fine.

The last part "Maybe people should be thinking about porting xcb to non-Linux platforms?" is still unclear to me, even though I asked Havoc to explain what he meant.

Finally, Thiago refused to merge the patch:

[…] thanks for the patch, but like Havoc I am unsure of the value. We can't drop the X11 codepaths now because too many systems exist without XCB. Adding the XCB codepaths only made it more complex, even though you did a good job.

I can't disagree with that conclusion: using both XCB and X11 make the code unreadable for little gain. That's why I did replace libx11 by XCB directly in the first version of the patch. On the other hand, D-Bus people does not seems to really care about making their software evolve in the right direction, even if that requires users to upgrade their systems.

I think D-Bus using and depending on XCB would have been a good point to push adoption of XCB. Unfortunately, it seems you can't even rely of projects of the same initiative (i.e. Freedesktop) to work together to make things a little bit better.

After 5 years of existence, XCB is still not so obvious to people, and making it adopt is going to be a challenge for the next years. The upside is that new X.org 7.6 will bring XCB with it, as part of the katamari.

29 Jul 2010 12:00am GMT

I got to the Textures session a bit late because I went to Nvidia's "OpenGL 4.0 for 2010" session, and the session went over by 20 minutes. It was a good overview of OpenGL 4.0 / 4.1. Nvidia (Mark Kilgard, more precisely) continues to spread mis-information about the compatibility profile, and that's really frustrating.

I missed all of By-Example Synthesis of Architectural Textures and everything except the results of Synthesizing Structured Image Hybrids. The results in the later were very cool. I especially liked the synthesized pirate flags.

Every year there's some piece of cool tech at SIGGRAPH that I want to implement. I think Vector Solid Textures is it this year. It's a very clever method of compactly storing volumetric textures as a sort of voxelized SVG. The complex step, of course, is generating the texture data. Any algorithm that utilizes sub-algorithms with names like "L-BFGS-B minimizer" and "teleportation" is bound to be frightening. lol.

The Mesh Colors presentation started with an excellent overview of all the problems with 2D texture mapping. If he had stopped there, I would have called it a useful presentation. Of course, he didn't stop there. The idea behind mesh colors is that a set of colors are stored for each triangle (one per vertex, one per edge, and N per triangle) along a tessellation grid (basically). At run-time the UV value is used to weigh the nearest colors. The frustrating bit of the presentation was the massive amount of hand waving (shown in the photo below) about the implementation. I suspect the details are in the paper. The hair farm shirt was a nice touch.

It also seems like there is a lot of area for future research. The filtered performance is pretty poor. I had a brief discussion with Cem about using hardware tessellation (to a level that matches the mesh colors pattern) to solve some of the filtering issues. It seems like it could work in some cases, but it presents problems of its own (i.e., potentially a lot more work for the rasterizer).

I may have to implement this algorithm too.

There were a bunch of cool things in the poster session, and I took the opportunity today to talk to some of the authors. There were several useful posters about soft-shadow algorithms, a couple about image enhancement, and a couple about ambient occlusion. I especially liked Curvature depended Real-Time Ambient Occlusion (sic). They use a preprocess to determine the concave curvature at each vertex. At run-time, this is interpolated, and the interpolated to determine the AO. The interpolation here gives a better result vs. per-vertex AO in the same way that interpolating light parameters gives better results than interpolating per-vertex light calculations.

My two favorite posters were GPU Ray Casting of Virtual Globes and, I kid you not, A Physical Rendering Model for Human Teeth. I plan to add both of these to my VGP curriculum. The tooth shader is useful because it shows a case of a lighting model developed for a specific type of surface.

The other poster that really caught my eye was the WebGLU poster. It sounds like Benjamin is doing a lot of the same things for WebGL that I'm doing for desktop GL. He and I talked, and there may be some colaboration in our future.

There are some things to really like about Open Shading Language. Being able to arbitrarily connect shaders (via matching inputs and outputs) in a DAG is something that I've been talking about doing in OpenGL for years. Pulling data out by specifying an arbitrary expression on shader outputs is also genius. In OSL the data gets dumped as an image, but I still see use for this in GL.

The implementation of automatic differentiation is really, really smart. I suspect that something like this could even be implemented in our hardware shaders. This would allow higher quality derivatives in some cases. I guess I need to read the Piponi paper from journal of graphics tools.

And they now use LLVM.

Since this system has texture mapping support in this system, this might make an interesting test bed for my thesis work. Hmm...

REYES Using DirectX 11 wasn't too interesting to me. During the Q-and-A period, someone (the previous presenter, in fact) asked what could be changed in either DirectX or the hardware to make this either easier or faster. Being able to insert compute shaders directly into the pipeline (to eliminate the intermediate buffers, synchronization, etc.) would have helped a lot. This isn't the first time I've heard a request for this.

The WebGLot: High-Performance Visualization in the Browser guys are doing some really cool stuff on top of WebGL. We'll need to use this app to test WebGL on our drivers!

The Gazing at Games: Using Eye Tracking to Control Virtual Characters course didn't feel like a course. It felt like a presentation of a survey paper on what people have done related to eye tracking in games. I got references to a bunch of papers that seem interesting, but that's about it. I do like the idea of "smart text." Text (dialog, etc.) is displayed until you look away from it. I had to leave early to go to the OpenGL BoF, so I probably missed the best parts. shrug

The highlight of the OpenGL BoF was, of course, the announcement of GLU3 as part of the OpenGL SDK. Getting a round of applause was cool.

One of the trivial questions was, "What ARB extension has not been shipped in any publicly available driver?" Answer? GL_ARB_shading_language_include. Damnit!!! Okay, we need to add that to our compiler todo list. Ugh. It's a cool feature, and John Kessenich, Jon Leech, and I spent a lot of time working on it. In all fairness, GLSL needs a much better module mechanism than it currently has. I have some ideas, but they'll have to wait until our new compiler actually ships at least GLSL 1.30.

28 Jul 2010 10:12pm GMT

The Importance Sampling for Production Rendering course was interesting, but a lot of it was review. I hadn't noticed that the first presenter in the course was also the author of the GPU-Based Importance Sampling from GPU Gems 3 that I use in VGP352. The bits about multiple important sampling and the bits about resampled importance sampling for shadows from the second presenter were new to me. There was a question from the audience about the Lafortune BRDF. Matt's response echoed what I say in VGP352 every year. He says that the Lafortune BRDF is not used at IMD beause it is "too uncontrollable for many artists."

I don't really know anything about REYES, so most of Micropolygon Ray Tracing With Defocus and Motion Blur was lost on me. The hyper-trapezoid BVH was interesting, though. Real-Time Lens Blur Effects and Focus Control was similarly a loss. The foreground occlusion image may find a place in VGP352 when I talk about depth-of-field effects. OptiX: A General Purpose Ray Tracing Engine was mostly an advertisement for Nvidia's ray tracing engine. There were a couple interesting bits about their compiler architecture, but meh.

To this point, I wish I would have gone to the An Introduction to 3D Spatial Interaction With Videogame Motion Controllers session instead.

That changed with Reducing Shading on GPUs using Quad-Fragment Merging. One of the opening tidbits will annoy keithp to be sure. "...one of the better ideas of real-time rendering [is] multisample anti-aliasing." In any case, their method of merging quads (2x2 pixel blocks processed by the fragment shading hardware) is fairly straight forward, but still clever. They track facing and connectivity for covered pixels in each quad. Multiple quads that have connected triangles with the same facing are merged. This can save a lot of processing.

Much to my joy, the Making of TRON: Legacy session got moved to Tuesday evening... when it didn't conflict with anything that I wanted to attend! w00t! Yes folks, that is the line...

EIGHT MINUTES of footage from the movie. A new trailer (I want one of those lightcycle throw pillows). Full on awesome.

A couple interesting bits:

• Daft Punk is doing the music, and they have a cameo.

• Some of the concept drawings from the original movie that couldn't be done on computers at the time was used. For example, the original lightcycles had the rider on the outside. There was no way the computers of 1982 could render that, so the design was changed.

• It was filmed in 3D, but, in the words of the director, there's no "spear poking you in the eye" business.

In the Q-and-A session I asked a semi-smart ass question. That's how I roll. "My biggest disappointment with the film industry came when I was 8 and the original TRON wasn't nominated for an Oscar because it "cheated" [by using computers]. Come January, is it going to be lightcycles or broomsticks? TRON or Harry Potter?" Yes, I know the Oscars are in March. I was nervous. Unfortunately, their answer was way, way too serious. "Ultimately that's up to you, but we think our work will stand on it's own." meh.

UPDATE: One thing I forgot before, there was an off-hand mention by the director that some effort was going into doing a "re-imagination" of The Black Hole. That was such a creepy movie! A re-make could be awesome... or horrible.

27 Jul 2010 8:52pm GMT

Ryan, Juerg and myself are all at Den Haag for GUADEC already for the whole week, Rob will be around by Wednesday. We will be giving away Codethink tshirts during the next few days, so come to poke us if you want one (we have a batch for girls btw!)

See ya around!

26 Jul 2010 10:19pm GMT

This year I was finally smart enough to register at the conference the day before it starts. Yay me. That made is so much easier the first day.

I wasn't expecting a lot from envLight: An Interface for Editing Natural Illumination, but I was pleasantly surprised. There were a couple of surprises in their results. I keep meaning to implement some sort of parameter editing interface for my BRDF demos, and I would have done it quite differently before seeing this paper.

I understand the method in Interactive On-Surface Signal Deformation, but I don't really get how it would be implemented in a real system. I guess that's what I get for not reading the paper before attending the presentation. I would have read the paper if I had remembered to bring the DVD drive for my laptop. That's the one annoying thing about the X200s... no built-in optical drive. In any case, it seems like this approach could be used to great effect in a demo. I imagine a scene where, say, the shock wave from a heavy object hitting the ground causes shadows on the ground to get pushed away.

My first Avatar presentation, PantaRay: Fast Ray-Traced Occlusion Caching was impressive. I guess rendering scenes with 10M to ONE BILLION DOLLARS... er... one billion polygons needs some new acceleration techniques. And a petabyte of "live data" needs some kick ass I/O. There are so many different optimizations implemented here that I think they could have gotten multiple papers out of it. Seriously. Just the layers of optimizations in the spatial index calculation should have been sufficient. Showoffs!

On a whim, I went the SIGGRAPH awards presentation. The cool thing there was a visualization app that shows, on a map of the world, where every technical paper ever published at SIGGRAPH originated. It will supposedly be posted on the web, so I'll link it here soon. The talk by Don "The Tornado" Marinelli really made it worth it, though. You can tell that he comes from a drama background. They also said that some of the content would be posted on YouTube, so his talk may get linked here later.

The word(s) of the day: deferred shading. Screen Space Classification for Efficient Deferred Shading was the first of the bunch. The basic technique is to read back the G-buffer to generate a batch of polygons to draw. The screen is divided into tiles, and the tiles are classified by attributes (e.g., in shadow, direct lit, etc.). On both PS3 and Xbox360 it cuts the frame time by about half. They talked a bit about the optimization of the polygon submission. Since the polygons are tile aligned, it seems like some sort of quadtree could be generated and rendered using point sprites. I'll have to think on that a bit more.

"Boom. 60 is better." lol. How to Get From 30 to 60 Frames Per Second in Video Games for "Free" uses the Z-buffer and the velocity buffer from the current frame and the color buffer of the previous frame to generate an in-between frame. The author was inspired by MPEG motion vectors. Here, it's a big hack. It has a bunch of hacks on top of it to fix artifacts. The best part is the way dynamic objects are "erased" from the frame (this is only necessary with deferred shading). I like it.

Split-Second Motion Blur covered some additional work from Split Second. They render a per-pixel 2D motion vector ID. This ID is then used in a blur post-process. In addition, they update the texture sampling derivatives based on the motion vector. Cheap, easy, good results. I'll definitely add this to the motion blur techniques covered in VGP351 next time it comes around.

Over the last couple years systems for indirect lighting in real-time have been all the rage. Pretty much all of them have used deferred shading. A Deferred-Shading Pipeline for Real-Time Indirect Illumination is shock no different. However, they're algorithm has good quality and speed. The other algorithms that I have seen pick one or the other. They incorporated a clever way to include occlusion for bounces, but this costs a lot of memory. I guess that's the trade off. The method for mipmapping the G-buffer was pretty clever. At each downscale they average the attributes from the largest object. This is sort of a bilateral filter in reverse. It's still screen space, so it has some drawbacks:

• losing indirect light from an object that goes off screen

• no support for mirrors reflecting objects behind the camera

Also, if I hear "current console hardware can't" one more time, I'll puke... or just roll my eyes again. I knew realize dynamic branching was bad on PS3, but I didn't it was so bad on Xbox360. sigh...

I wrapped up the day with Live Real-Time Demos. As Eric Haines notes, they were pretty cool. Thinking back to my days as a demo coder, it brings a tear to my eye to see demos on the big screen at SIGGRAPH.

26 Jul 2010 4:19pm GMT

The full Collabora Multimedia crew is in The Hague this week for GUADEC and our annual get together. It is the first time all 12 of us are together and its nice to spend some time face to face to get to know each other beyond IRC.

Currently doing a little hackfest at our hotel, pushing forward some cool stuff like echo cancellation, PiTiVi and more.

26 Jul 2010 1:00pm GMT

Made it to the venue today, and am currently enjoying my 10th GUADEC. I'm still behind jrb :)

26 Jul 2010 11:40am GMT

Phoronix published a sensationalist article last week claiming that my regular e-mail updates of our biweekly builds somehow signified some out of the ordinary newsworthy event, without bothering to do even the most basic of fact checking. While I pointed this out in their forums within hours of publication, I'm still seeing it cited by other web magazines that don't bother to fact check, as well as in various e-mails and blogs, so am publishing a more complete explanation here of why it really is a non-event.

The article claimed:

As the first email of its kind in months, Alan Coopersmith who is a known X.Org contributor and longtime Sun Microsystems employee now working for Oracle, has written a new email entitled "IPS distro-import changes needed for X packages for nv_145." Alan immediately began this public email by saying, "Just when you thought you'd never see another one of these biweekly mails..."

Sadly, all they needed to do to disprove the claim that it was the "first of its kind in months" was simply follow the links from the e-mail archive page they linked to, to see that I had sent a similar message two weeks earlier for the previous biweekly build nv_144. In fact, if they checked the archives for previous months, they would have found that, except for missing build 143 (a mistake on my part), I've sent these approximately every two weeks for every biweekly build for a very long time.

Perhaps I'd confused the article's author with the offhand comment he seems to have misinterpreted, but explaining that requires a bit of background explaining what these e-mails are and why I send them in the first place.

As many OpenSolaris users know, over the course of the last couple of years, we've been transitioning from the old SVR4 package system used in Solaris 2.0 through Solaris 10 to the new Image Packaging System (also sometimes known as "IPS" or "pkg(5)") being developed by a team of Solaris engineers and community members. Initially, we maintained two parallel distros, Solaris Express: Community Edition (SXCE), which was built using the SVR4 packages and the old Solaris installer that worked with them, and OpenSolaris (originally codenamed "Project Indiana"), which was built using the IPS packages and the new Caiman install software designed to work with them. The teams providing the package contents continued to deliver SVR4 packages, and the OpenSolaris distro team converted those to IPS.

One of the goals of the OpenSolaris distro was to provide a set of ISO install images and package repository that was completely, freely redistributable, so that it could be easily mirrored, copied, and downloaded without having to deal with the various encumbrances required by some of the third-party licenses in the traditional Solaris and SXCE packages. Unfortunately, at that time, we had not yet finished separating the encumbered code from the open source code in our X packages so that they could be included, since when Sun made its proprietary fork of X11R6 in the early 90's, the engineers never figured we'd be open sourcing Solaris a decade later and need to easily separate out the encumbered bits they were merging into the main code base.

The initial Developer Preview releases of the OpenSolaris distro thus included a set of X packages that Moinak Ghosh built from the Fully Open X (FOX) project work we'd done to rebuild our source trees from the ground up using the open source code from the X11R7 modular releases in order to ensure everything was either open source or cleanly separated out. Over the first few months, we migrated from those to the packages our team delivered to the OS as we integrated the FOX project work into our main source tree. Because these changes weren't always obvious to the external observer, I started sending notes for each biweekly build to let the team maintaining the SVR4 to IPS conversion tables know which parts of our packages they could now include, as well as any other changes they needed to know about, such as version number changes. (Our SVR4 X packages all used the same version number, a holdover from the monolithic X source days, but we've migrated to using the upstream version numbers as much as possible in the new X IPS packages.) I did this not only to try to help the distro building team, but also to help myself keep on top of the changes they made in converting our packages, so that we could understand issues users hit and know how to help them, and to learn better what we'd need to do when it came time for us to start building the IPS packages ourselves.

Last year, Sun announced that the time had finally come to start converting the builds to generate IPS packages directly, taking the next step in transitioning off SVR4 and ending the production of the SXCE distro, since the SVR4 packages used to build it would no longer be made. The ON consolidation went first, converting the packages containing the kernel, drivers and core utilities in build snv_136. The Install consolidation went next, in build snv_143, and X followed in build snv_144.

So, when I wrote "Just when you thought you'd never see another one of these biweekly mails...", I simply meant that after build 144, all the X packages are already delivered in IPS format, so there are no SVR4 to IPS conversion files to update for them any more, so I won't need to send those - except in cases like we had in 145, where I relocated one of the files that was listed as a dependency in one of the other packages still being converted by the distro builders, so they needed to update the dependency statement for it to list the new path to the file.

Despite what Phoronix seems to have assumed, I was not in any way referring to the limbo state the OpenSolaris distro is currently in (and unfortunately, as much as I'd like to explain that, I can't), nor stating anything about build 145 that is fundamentally different than the previous builds. It should come as no surprise to anyone that while build 134 was the last build to be publicly released, we have continued work on the Nevada builds after that - after all as we've said since 2005, Nevada is the code name for the development branch in which we're working towards the next full release of Solaris (i.e. not another Solaris 10 update release, but the one we may someday call Solaris 11) - while that's been released under various forms, as the OpenSolaris open source code, or via the binary releases of the original Solaris Express, Solaris Express: Community Edition, Solaris Express: Developer Edition, or the OpenSolaris 2008.05, 2008.11, and 2009.06 distros, we've always kept driving towards the same goal, with biweekly builds assembled to test the current progress.

My mail is hardly the only externally visible sign of this - you can see changelogs for the major consolidations (ON, SFW, X, and Desktop/JDS) for build 144 (the last fully finished build, as 145 is just finishing pre-integration testing now, with a delivery deadline of Monday for packages to be included, and the distro build process starting after that. Of course, the sources are also available, and there's plenty of activity on the various commit notification and discussion mailing lists showing that we're continuing to work away on Nevada.

So unfortunately, Phoronix succeeded in making a mountain out of a molehill, confusing their readers and fellow webzine authors, but likely meeting their goal of driving more traffic to their site to generate page views for their ad revenue as people passed the link around twitter, IRC & email or linked to it from their blogs & articles. As others have pointed out, checking the facts or contacting the developers to find out the story is less juicy than it seems doesn't play well with that business model (and that's not just true for Phoronix - look at any number of the columnists for other web-based "trade publications" that generate traffic via controversial posts, and the more outraged the community gets over them and angrily passes them around to denounce, the better their numbers are - you can just imagine how many of their articles are designed to bait Groklaw or Slashdot readers).

26 Jul 2010 5:53am GMT

I got myself a little Huawei E585 device, so that I can put in a data SIM card when travelling. My attempts at getting a 3G data subscription in the UK that wouldn't cost an arm and a leg when abroad completely failed, and I didn't fancy carrying a phone just to use as a modem when travelling (I use my usual handset through Bluetooth when in the UK).

Once in the Netherlands, I'll get a Pay-as-you-go 3G SIM card, top it up and subscribe to the cheapest data deal, and be done with it. Note that I needed to unlock the device for use with other carriers, using this dodgy looking website. But it worked as expected.

My attempts at finding the Linux code on the device failed (and this code doesn't seem to be it), so I also dropped a mail to Huawei's FOSS office.

23 Jul 2010 10:18am GMT

The 0.9 release is now available! I'm calling this 0.9 because not all of the functionality is available in the C interfaces. Once that is resolved and a couple other GLSL utilities are complete, I'll call it 1.0.

There is a tag in the GIT repo for the release. The glu3-0.9.1 tag is the "real" tag. I pushed the glu3-0.9 before doing make distcheck, and, of course, there were errors.

md5sums:

75032c9aaf2d279738ce3940383439ff  GLU3-0.9-20100721-bin.zip
63ccdbdb8d6799b9a530b661f1d9d0f7  GLU3-0.9-20100721-src.zip
862b22f67dd7d6f087ff6ba497653621  GLU3-0.9-20100721.tar.bz2
6266c6944128eec4149c8b8101e290df  GLU3-0.9-20100721.tar.gz

21 Jul 2010 8:43pm GMT

The last week I've been trying to get presubtract operations working for the r300 compiler. Presubtract operations are basically "free" instructions that modify source values before the are sent to the ALU. The four presubtract operations for r300 cards are (1 - src0), (src1 + src0), (src1 - src0), and (1 - 2 * src0). At this point the compiler only uses (1 - src0), but now that I have one working adding the others shouldn't be too hard. I had to make some major changes to the compiler to get this working, so I am going to let it sit in its own branch (presub branch at http://cgit.freedesktop.org/~tstellar/mesa/) and test it out for a while before I merge it into the the master branch.

20 Jul 2010 1:30pm GMT

I thought I should share a sneak peak on a small patch I've been working on to add support for markers support in GtkScrollbar, the idea is to add support for hints in things like search matching, or where in the backlog someone named you in a chat dialog. Here's a screenshot of the result in the default theme:

This should bring Google Chrome-like search functionality to gEdit and Epiphany! Now if only I had some time to work on a set of standard inline dialogs to avoid windowed ones :-)

The patch, against Gtk+ master, is pretty much done, waiting for a reviewer to point out any pending details. If everything goes alright it should land for 3.0, subscribe to the bug if you want to track its progress. :-)

19 Jul 2010 10:25pm GMT