Buy a COOP sticker, go to jail: "Stickers on a Clovis man's car portray cartoon images of bare-breasted female devils in sexually compromising positions. And the images have caught the attention of Clovis police. Officials have charged 31-year-old Dean Young, the owner of a yellow Ford Focus displaying the images, with distribution of sexually oriented materials to minors. The charge is a misdemeanor carrying a maximum punishment of 364 days in jail and $1,000 fine."
The U.S. House of Representatives approved on Thursday a sweeping set of rules aimed at forcing states to issue all adults federally approved electronic ID cards, including driver's licenses.
And in the same bill:
Bill passed in House also empowers security secretary to 'waive all laws'
Section 102 of the REAL ID Act of 2005 seeks to expedite the building of a three-mile fence at the border near San Diego to staunch the flood of illegal aliens that travel through an area known as "smuggler's gulch."
Environmental laws have been the project's chief roadblock, but the bill's language appears to provide an unlimited scope, reading, "Notwithstanding any other provision of law, the Secretary of Homeland Security shall have the authority to waive, and shall waive, all laws such Secretary, in such Secretary's sole discretion, determines necessary to ensure expeditious construction of the barriers and roads under this section."
Significantly, it also says courts are prohibited from reviewing the secretary's decision.
The saga continues:
Plus bonus drunken yuppie action!
When loading images, I used to do this:
That has been working for some time, but it was slow: copying and converting the image cost me about 0.1 second per image. I thought to speed that up by cutting out that "conversion" phase and doing it like this instead:
<LJ-CUT text=" --More--(12%) ">
strangehours had the inspiration of the sensible way to compute the GL format/type values to use, and with that last test, it was working.
But then when I plugged it in to the real code, I found that it had gotten slower instead of faster! Apparently if you use a "packed" type, instead of using GL_BYTE and passing each color component in separately, GL takes six times longer to construct the texture. I guess the way packed types are implemented internally is by converting them to something else first, and that conversion is even slower than the conversion I had been doing originally.
So, yay, that was a big waste of time.
The actual problem I'm trying to solve here is that when you run the glslideshow screensaver (the one that pans/zooms through a series of images, in a direct ripoff of the MacOS X slideshow screen saver) there's a visible glitch every time a new image loads. In the currently-released version of xscreensaver, that glitch could freeze the animation for up to a couple seconds, since it was waiting for the image to be loaded from disk and everything.
I've fixed most of that problem by loading the image file in the background. Once the image data is in memory, I get signalled, and only then have to stop and convert it to a texture. So that glitch is down to about 0.1 or 0.2 seconds now. But I was trying to shave some more off that time (which was the point of that whole exercise earlier.)
In glslideshow, image loading happens in three stages:
When that completes, a callback informs us that the pixmap is ready. Then we download the pixmap data from the server with XGetImage (or XShmGetImage.)
Convert the XImage data to a form OpenGL can use.
Finally, construct a texture.
So, the speed of step 1 doesn't really matter, since that happens in the background. But steps 2, 3, and 4 happen in this process, and cause the visible glitch.
Step 2 can't be moved to another process without opening a second connection to the X server, which is pretty heavy-weight. (That would be possible, though; the other process could open an X connection, retrieve the pixmap, and feed it back to us through a pipe or something.)
Step 3 is what I spent the last few days trying to optimize, and failed.
Step 4 is also hard. I can't just fork() and load the texture in another process, because glXCreateContext says:
An arbitrary number of contexts can share a single display-list space. However, all rendering contexts that share a single display-list space must themselves exist in the same address space. Two rendering contexts share an address space if both are nondirect using the same server, or if both are direct and owned by a single process. Note that in the nondirect case, it is not necessary for the calling threads to share an address space, only for their related rendering contexts to share an address space.
So I think that means that the only way two processes can share GL state is if you turn "direct" off, which I think means that they run unaccelerated (or perhaps only "less accelerated"?), because they're going through the GLX protocol instead of talking to the hardware directly.
I think that maybe threads running in the same process might be able to share accelerated GL contexts, but xscreensaver doesn't use threads now, and I really don't want to deal with the portability hassle of adding them.
I guess the Apple saver must be doing this by loading the textures in a shared-address-space thread. I think that's probably the only way to make this work.
Blah.
Also, the API for shared-memory XImages is just stupid. There's so much book-keeping you need to do around them that I'm pretty sure I'm leaking shared memory segments, but fuck if I know what to do about it... Seriously, go read the code in xscreensaver/utils/xshm.c and feel the pain! The XShmSegmentInfo data has to have "at least" the lifetime of the XImage itself, so you've got two things you need to pass around to every user. There is a destroy hook on XImages themselves, but (I think) the hook on SHM images free only the server side of the shared segment, not the client side; you have to do that explicitly.
I'm tempted to just turn off XSHM in xscreensaver under the assumption that on modern machines, the speed advantage isn't worth the hassle.
