semi/signal

This involved drawing a filled rectangle with a TextureBrush, using a 1x[whatever] texture and setting it to be tiled.

The code above works correctly and here is what it produces,

Unfortunately if the y (top) coordinate of the rectangle is changed to anything other than 0, the rendering gets screwed up. Here is what occurs if the y-coordinate is set to 1 (which should, effectively, push everything down 1 pixel),

However, there is a way to hack around the issue, keep the y-coordinate at 0 and use Graphics.TranslateTransform() to do the y translation.

A while back I wrote about 2 applications, The KMPlayer and JCreator not behaving well when attempting to run both concurrently (see post).

Now, I have an incredibly weird situation on my system. KMPlayer and JCreator don’t play nice together. If they’re both open, some JCreator panels and menus are suddenly blank and don’t refresh and the side tabs panel is transparent, showing thru to the desktop. As for KMPlayer, I can’t open anything, clicking play (which plays the last file opened when nothing else has been loaded) does nothing, and certain items are mysteriously missing from the context menu. This hasn’t been a big deal for me, and I still use both JCreator and KMPlayer, but it would be nice if they worked together. Also, I have to wonder, what is the common component causing the conflict here, what would a media player and a java IDE both be using or trying to access concurrently? (assuming there is a conflict for a common component, which I suspect might be the issue here)

My suspicion was wrong, it was not a conflict between the applications or a common component, it was the system running out of User objects. In Winforms (and I suspect most other GUI toolkits as well) any GUI control or window will consume at least 1 user object (more complex controls, with multiple sub-components will consume more User objects), and when the system or process hits the limit (65,536 for the user session, 200 – 18,000 per-process; default is 10,000 on Windows XP), creation of new User objects will fail, even if the system has enough memory to support whatever it is that’s being created. On the .NET Framework, you’ll notice this if you get an exception that looks similar to the following,

System.ComponentModel.Win32Exception: Error creating window handle. at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp) at System.Windows.Forms.Control.CreateHandle() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl()

I’m still puzzled as to why there simply isn’t a limit based on available memory, but I haven’t been able to find a whole lot written on User objects in general much less details on why they exist.

I spent some time recently investigating file tagging on Windows Vista and Windows 7, and I was less than happy with my findings. The problem is that only certain file formats that support metadata can be tagged, for file types without such support it’s simply not possible to do any tagging. This is a major limitation and without ubiquitous tagging support, the feature itself becomes all but useless; as an end-user, I don’t care about file type, if I’m searching for a document should I have to remember whether it’s a Word document or a plain-text file? JPEG or TIFF? Absolutely not. The confusing thing is, at some point, Microsoft seemed to believe this as well, by default Win 2000 and higher hides file extensions for know file types – isn’t it then completely counter-intuitive to present a limitation based on file type. What this ultimately boils down to is the question of why would I bother tagging anything if only a subset of my files, based on file type, an attribute I don’t care much about, would benefit from the additional metadata?

This isn’t to say that there is necessarily an easy solution. I found this blog post to be the best write up on the topic which explains several approaches that could be taken to implement tagging and why storing metadata in the files themselves was chosen as the best approach. However, I don’t think storing metadata in the file system would be such a bad idea, I can understand the issues about losing metadata when copying to another volume, typically one with a older file system, but at some point you have to do what’s best for the future, not the present, by that I mean the only way you’d actually start to see file systems with proper support for metadata (via. NTFS-esque alternative streams or whatever) in use is by providing an imperative for users to buy or format devices with those file systems; as-is, we’ll continue to use systems such as FAT32 and programmers will continue to remain agnostic to metadata. At the very least, a hybrid approach, storing metadata both in the file itself, when supported, and within the file system would seem a worthwhile solution.

I’m not an artist, but I think this is a pretty great message and can be extrapolated pretty easily to other professions and to those of us who are starving artists in spirit,

Link

I always forget how to do this:

• Tools » Options » Show all settings (checkbox in lower-right)
• Projects and Solutions » General » Show advanced build configurations (checkbox)

h/t: Ramon Smits

I came across this great photo essay a while back regarding a unique and impressive form of housing found in rural China, the Tulou, used by the Hakka people.

The Tulou is typically a large enclosed building, rectangular or circular in configuration, with a very thick weight supporting earth wall (up to 6 feet thick) and wooden skeletons, between three and five stories high, housing up to 80 families. These earth buildings usually have only one main gate, guarded by 4 to 5 inch thick wooden doors reinforced with an outer shell of iron plate. The top level of these earth buildings has gun holes for defense against bandits. They are a testament to the unique cultures that exist throughout China.

Don Ivan Punchatz, the artist who helped id Software launch Doom to a greatness by designing the artwork on the box and promotional materials, has died of cardiac arrest.

Don’s work was best known to gamers for his efforts on the Doom packaging – the iconic image of the space marine shooting down into the hellish hordes – but that was only a small part of his work. His styles varied hugely between photo-realism and surrealism and he was affectionately known as ‘The Godfather of Dallas Illustration’ for his work in founding Sketch Pad Studios, which helped launch other artists to greatness.

h/t bit-tech.net

If your going to speculate (wildly) regarding technical details about the Apple tablet in relation to the iPhone, at least try to get the fundamental details in question correct. Case-in-point.

For an Apple Tablet to be a hit, it will have to be more than a big-screen iPhone. And the difference between a lithe, touch-based Mac and a giant, lame iPhone comes down to one crucial nerd-factor: memory management.

When your program closes, your app is supposed to give back all that memory to the OS, so that it your computer can use it for other apps. If your program doesn’t give back memory to the system, it’s called a “leak.” Leaky programs are bad; they make things crash.

This sounded fishy, and it is – the iPhone OS, like most modern OSs, will reclaim memory when an program terminates. A program with a memory leak will not cause anything to crash, but running out of memory will force the OS to forcefully terminate apps (which is not the same as a crash).

It [Apple Newton] supported garbage collection, or automatic memory management, just like full-grown desktop Macs. What’s the difference to you? More powerful apps.

There is no correlation shown between garbage collection and more powerful applications. Many complex, powerful and high quality applications are written in languages that don’t support garbage collection; for example, Photoshop.

So iPhone apps tend to “leak memory,” or hang on to memory too long. Developers I’ve interviewed–even Apple Design Award winners–have mentioned to me that their iPhone apps are leaking memory almost constantly because they’re too lazy to be really anal about manual memory management.

Read: lazy developers designed apps with crappy architectures that couldn’t handle reliable deallocation of memory.

But this means iPhone apps can only get so complex before they require too much hand-tuning to be worth the time.

“worth the time” is entirely dependent on the developer and the purpose of the app. If a more powerful app is worth it to an individual or company, they’ll make the investment to build an app with a more robust architecture and better memory management.

Garbage collection is certainly a nice feature to have, but it’s not a silver bullet for developers.

The .NET Framework has no methods to get the MIME type of a file and, as I was in need of such functionality a while back, I’m glad I found this post on CSharpFriends.com (UPDATE: removed link, CSharpFriends.com is dead) which presents a switch statement that maps numerous filename extensions to the appropiate MIME type.

I was somewhat dismayed that someone mentioned using the system registry to lookup the MIME types, and the OP seemed to have gone with this method. Using the registry cuts down your codebase, but that’s little more than a convenience; there are some important issues that pop up when using the registry in this situation:

• It only works if the file extension is known to Windows; either the version of Windows the app is running on knows of the file extension or an application puts the file extension into the registry.
• It binds (read: couples) your app to a third-party component, in a situation where there is no need to.
• It locks you into a specific platform (i.e. it won’t work with Mono). Even if it’s not a major issue, there’s no reason to lock your app to a certain platform when you don’t have to.

UPDATE: As CSharpFriends.com is dead, the code I derived from the original post is below. The FromFileName() function will take a filepath, get the extension from the filename, and return the MIME type of the file.

Last month physicists at the Kharkov Institute for Physics and Technology photographed the electron cloud of a single carbon atom. The images are the first real photographs of the electrons of a single atom, showing the s and p orbitals of a carbon atom.

Quantum mechanics states that an electron doesn’t exist as a single point, but spreads around the nucleus in a cloud known as an orbital. The soft blue spheres and split clouds seen in the images show two arrangements of the electrons in their orbitals in a carbon atom. The structures verify illustrations seen in thousands of chemistry books because they match established quantum mechanical predictions.

… and as for how it was done…

To create these images, the researchers used a field-emission electron microscope, or FEEM. They placed a rigid chain of carbon atoms, just tens of atoms long, in a vacuum chamber and streamed 425 volts through the sample. The atom at the tip of the chain emitted electrons onto a surrounding phosphor screen, rendering an image of the electron cloud around the nucleus
…
The sharper a sample’s pointed tip inside the vacuum chamber, the greater the resolution of the final image on the screen said Igor Mikhailovskij, one of the paper’s authors. In the last year, physicists learned to manipulate carbon atoms into chains. With the tip of the sample now just a single atom wide, the microscope was able to resolve the electron’s orbitals.