What I don't understand is why real "changing resolution on the fly" is not added to XFree86. It should be easy, they already do the hard part which is to change the hardware so the memory is drawn on the screen differently.
The only other thing X keeps track of is the size of the root window. I propose that the server send a ConfigureNotify event to whoever is listening to the root window (probably the window manager) indicating the new size. The window manager can then respond to this by moving and resizing windows (using whatever rules it wants) to get the resized display. Of course the window managers will need to be rewritten but I expect this would happen very quickly.
The only other thing is the screen size macros on the Display object. It would also help if xlib was changed so requesting the screen size either did a round trip or a signal was added to indicate that the local copies need to be updated. However I don't think this is vital and it can be ignored as most applications don't use the screen size for anything except to figure out the resolution.
I'm suprised that anybody is reading this old of an article. But anyway I see no difference than somebody saying "C is safe, just use this special at(pointer,index) function instead of [] and you will be fine" The normal syntax everybody uses is not bounds checked and there is no way around that.
Yes, MALLOC_CHECK_ has worked for me to find bugs as well. This was in a portable program that we tried to locate the bug on Windows using Purify and gave up on locating, MALLOC_CHECK_ found it right away (the bug was in an automatic constructor). Though I doubt this is normal, it sold me on using the simple tools.
Setting MALLOC_CHECK_ to zero makes it act the same but not abort or print messages. The weird end result is that malloc is safer because a side-effect of the checking is that multiple frees and writing off the end of a buffer. I think it may actually do the tests and then decide not to report the results, so it certainly is slower.
Shake uses OpenGL for it's GUI, but not for the compositing calculations. You may be confusing it with Discreet Logic's Inferno things, which rely on OpenGL hardware to do the work.
For very large sequences of operations, scan-line rendering is considerably faster and require many orders of magnitude less memory. There is no way to avoid it. Any compositor not designed to work this way will be limitied to a small number of operations before the image must be written back to disk.
From experiments with Rayz it seemed to be scan-line oriented just like Shake and Nuke.
At the API to the system level, the seperator is slash. At some point after you typed in the 15/06/02 filename, some library or app replaced all the slashes with colons. This is the filename that was passed to the system through the Unix API.
Later on the shell used the Unix API to get the filename, and retrived the filename with the colons. The changes were made when the file was created, not when the shell listed it.
You may be confused because the HFS probably (I don't know for sure) translates colons in the names back to slashes so that the disk image can be read by OS9, and translated them back when read. However you could make a filesystem that rot13 or otherwise mangled the filenames when storing, but that fact is totally invisible to a program that does not examine the actual disk blocks, so that fact can be ignored.
I am disappointed to see Apple favoring slashes in names over colons. The OSX finder will translate slashes to colons and back again, while translating colons the user types into into dashes and not back again. I would prefer if they turned slashes into dashes and left colons alone. This current scheme messes up two letters instead of one, also allowing people to think they can put slashes into their filenames is going to mess them up when they try to make web pages (which Apple seems to be pushing...)
You've got it backwards. Far more people make money off GNU software than would off some kind of copyright-less music. I make a good deal programming Linux machines. I have never heard of a company hiring a musician to compose music for internal use only by the company.
#2 is probably false. Closed source would have a lot of advantage, especially for stopping any program other than your own from interpreting the data manipulated by it. This is of course the source of MicroSoft's power, they actually relied on the free copying of their software to force their closed formats into all niches of the computer world.
Of course the legality of reverse engineering and disassemblers would negate this somewhat. A legal coorporation could attack these closed systems, not just hackers in their basement.
No digital form of distribution provides an equivalent level of moderation provided by the music industry, it is almost impossible to find the best quality content out of the giant databases
There you have just described a way to make money. Provide a service that allows people to find what they want.
As the text states this is a 180 degree fish-eye lens view. There are very few clues, but I suspect the rock blocks in the foreground are in fact in a straight line and not a curve like they look.
I suspect the bridge from that POV would be absolutely enormous and any normal camera lens would show only a small piece of it.
The professional equipment does not have SCMS. So it is quite possible that copy protection is the explanation for the consumer equipment failure, while the machines that lacked it succeeded.
For good reproduction you do need more than 8 bits per channel, but we don't need them put "inbetween" the colors that are already on the screen. What is needed is much higher dynamic range (ie much higher than a CRT can produce, but a DLP can produce such a range).
For the 400:1 contrast ratio between the brightest white and black screen of a typical CRT, 8 bits are enough, if they are distributed in a gamma curve such as the sRGB standard, so the black samples are closer together. The eye is quite incapable of seeing the resulting steps, unless large areas of two colors are adjacent. This can be solved by correctly dithering the image to 8 bits when rendering, or by adding noise if the data has been posterized already.
If they go to more bits I would like to see the maximum brightness increased by about 4 times and half the additional range of numbers used to represent colors in that brighter area. The other half of the numbers could be put between the existing brightnesses.
I very much believe no more than 10 bits are necessary, if correctly distributed. Cineon files used for scanning film have a good deal more range than real film and use 10 bits in a logarithmic representation, each number represents the 1.002 times brighter than the previous number.
Converting 8 bit RGB to 8 bit YUV and back is very lossy. The losses are when the floating point values are rounded to the nearest integer. Dithering can help considerably here. They could encoded the signal uses a non-lossy integer conversion of G, R-G, B-G, or the mpeg encoder could use floating-point inputs, so this is less of a problem.
Dammit you guys. "subpixel" means thinking about things that are smaller than a pixel. It does not mean ClearType. ClearType uses subpixel sampling.
There are about 3 ways to do anti-aliasing:
The very expensive way is to examine the actual paths you are rendering, how they intersect the pixels, and calculating the actual coverage of the pixels directly with math. This is probably what the original poster meant by "floating point". This is easy for infinitely long straight lines but very difficult for any other shape to do correctly.
A less expensive way is subpixel sampling, which is to use the normal black & white algorithim to render the letter about 4 times larger and then use 16 pixels (or sometimes weighted overlapping areas for better quality) to calculate the resulting gray from how many pixels are filled in. This can be done by hardware today and I believe is what is used by Quartz, the older Mac AntiAliasing, the new Windows AntiAliasing, and by Xrender for AntiAliasing. Note that some algorithims do the summation at the same time they calculate the subpixels, so there never is any "high resolution bitmap" in memory, but this does not change the basic algorithim.
The third way is to render at normal size and guess by looking at adjacent pixels. This is what Windows "Font Smoothing" did, I believe. A variation on it (producing shapes rather than grayscales) was used by early Macintoshes to render bitmaps onto higher-resolution printers. The primary advantage of this scheme is that it is fast, but otherwise it sucks.
ClearType is subpixel sampling with some multliple of 3 horizontally (not necessaryilly 1x3 as many people think, doing a higher resolution would result in better antialaiasing). These samples are then weighted-summed down to an image with 3 "subpixels" horizontally and one vertically. This is followed by a step I call "error diffusion" which is the clever part, to change the image by adding or subtracting some subpixels so the total amount or red, green, and blue are equal.
Okay, everybody, got it? "subpixel sampling" was used before Bill Gates first saw a computer, incidentally. It is NOT a MicroSoft invention, so stop making fools of yourselves.
There is also 1080p which is what I think is meant by "HDTV resolution". The pixels are square and it is 1920 pixels wide.
The projectors in use right now are 1280 wide and 1024 tall, and produce a 4/3 aspect image. This is projected through a panavision-style lens to stretch it horizontally. The reason the projectors are this resolution is they are designed for coorporate boardrooms to show PowerPoint presentations. I believe the manufacturers are working on new devices that are designed for cinema and are HDTV resolution.
Not sure if even maximum HDTV resolution is good enough, most digital effects for 35mm are done at 2048 wide and about 1108 tall, though some are done at 1828 by about 988 tall. Lots of people claim this is not good enough and 4096 wide is needed to accurately represent 35mm film.
Absolutely! A lot of the libraries and kludges being written for both Unix and Windows are to implement hierarchies of data in files, because individual files are too slow or have too much overhead. This needs to be fixed and we would be much better off of the effort going into designing the next mail went into designing a filesystem that allowed the "obvious" way to store mail to work.
NeWS was much better than DPS, in that everything (including the creation and management of windows and events) was PostScript. This made programming it considerably easier.
One unfortunate fact of NeWS is that too many people thought it's purpose was to preview PostScript before printing it, which is all DPS is useful for. That, and Sun's stupidity at not giving it away for the same price as X11, killed it.
I don't think there is a problem. The compressed video and sound are fine, as they are playable using the open-source code and can easily be considered the "usual form of the source". For instance you can easily imagine a game devloper who just keeps the compressed versions.
I think in fact you are trying to make a bogus example to show that the GPL won't work. It works fine.
As I understand the actual DSS algorithim was screwed up, so that knowing one key allowed you to easily derive all the other keys.
This sort of mistake could have been avoided if they had open-sourced the alogirithm (though not the keys). I think somebody would have analyzed it and pointed out the defect.
Then they could have stopped that one key.
However I'm not sure if the plan, even if correctly implemented, is all that good. If a key is compromised and they stop using it, they prevent not only the programs with that key, but also any players that use that key. Forcing everybody who owns such a player to buy a new one may not be the best public relations, and I would expect some DVD publishers to just give up and even advertise their disks "works on older Kenwood DVD players" (or whatever was compromised). Possibly even the publishers have signed contracts saying they won't do this, but I still see an enormous public-relations backlash.
Though the point-to-type works, it still raises windows on clicks. This effectively makes it impossible to have a "document" that requires more than one large window to display (for instance two different large-scale views of the same data, such as an image and a graph of the data structure). For this reason all such programs are using "tiled" window layout, which is as much of an abonimation as "MDI" was. We still have a long way to go before we get to the X window managers of 1985, unfortunately...
Even worse is the insistance of all new X window managers to copy this foul "click raises" behavior.
A huge breakthrough would be to ONLY RAISE THE WINDOW WHEN THE USER CLICKS ON THE TITLE. In particular stop raising it on clicks, and don't raise it when a child window is raised! If these simple changes were done we could have far better user interfaces with multiple overlapping windows than the crap MicroSoft's stupid decisions have forced us into.
Actually what you propose is quite common and can be done with the GPL. It is called "dual licensing", and Qt is probably the best-known example. You can use Qt in open-source code for free, but if you want to distribute closed-source code you have to pay for a different license.
Whether this is a nasty thing or not, Hollywood has got to learn that this is the only scheme that will work.
If they have any qualms about putting out enough information to write an open-source driver for their card, then they will be cracked. Any "secret" in the driver or OS means you are relying on security through obscurity will fail.
In case you don't understand how this works, imagine that the driver interface is like the interface between your remote control and the cable box. Completely disassembling the remote control and reverse engineering it would not let you get any more stations than you already do. And they have no qualms about copying the signals to those reprogrammable remote controls.
So in some ways this is not too bad: Either Linux will be supported, or the system will be cracked. However I don't expect them to be as smart as this and Linux will be outlawed and nothing will be done to stop piracy.
Slashdot Mirror
The only other thing X keeps track of is the size of the root window. I propose that the server send a ConfigureNotify event to whoever is listening to the root window (probably the window manager) indicating the new size. The window manager can then respond to this by moving and resizing windows (using whatever rules it wants) to get the resized display. Of course the window managers will need to be rewritten but I expect this would happen very quickly.
The only other thing is the screen size macros on the Display object. It would also help if xlib was changed so requesting the screen size either did a round trip or a signal was added to indicate that the local copies need to be updated. However I don't think this is vital and it can be ignored as most applications don't use the screen size for anything except to figure out the resolution.
Sounds like workstations for cel painting.
I'm suprised that anybody is reading this old of an article. But anyway I see no difference than somebody saying "C is safe, just use this special at(pointer,index) function instead of [] and you will be fine" The normal syntax everybody uses is not bounds checked and there is no way around that.
Setting MALLOC_CHECK_ to zero makes it act the same but not abort or print messages. The weird end result is that malloc is safer because a side-effect of the checking is that multiple frees and writing off the end of a buffer. I think it may actually do the tests and then decide not to report the results, so it certainly is slower.
does not do bounds checking.
For very large sequences of operations, scan-line rendering is considerably faster and require many orders of magnitude less memory. There is no way to avoid it. Any compositor not designed to work this way will be limitied to a small number of operations before the image must be written back to disk.
From experiments with Rayz it seemed to be scan-line oriented just like Shake and Nuke.
At the API to the system level, the seperator is slash. At some point after you typed in the 15/06/02 filename, some library or app replaced all the slashes with colons. This is the filename that was passed to the system through the Unix API.
Later on the shell used the Unix API to get the filename, and retrived the filename with the colons. The changes were made when the file was created, not when the shell listed it.
You may be confused because the HFS probably (I don't know for sure) translates colons in the names back to slashes so that the disk image can be read by OS9, and translated them back when read. However you could make a filesystem that rot13 or otherwise mangled the filenames when storing, but that fact is totally invisible to a program that does not examine the actual disk blocks, so that fact can be ignored.
I am disappointed to see Apple favoring slashes in names over colons. The OSX finder will translate slashes to colons and back again, while translating colons the user types into into dashes and not back again. I would prefer if they turned slashes into dashes and left colons alone. This current scheme messes up two letters instead of one, also allowing people to think they can put slashes into their filenames is going to mess them up when they try to make web pages (which Apple seems to be pushing...)
Would I be upset if somebody stole my computer? Yes. But would I be upset if somebody copied my computer? I don't think so.
Actually this is probably a troll, since this argument about IP is so easily made to look ridiculous.
You've got it backwards. Far more people make money off GNU software than would off some kind of copyright-less music. I make a good deal programming Linux machines. I have never heard of a company hiring a musician to compose music for internal use only by the company.
Of course the legality of reverse engineering and disassemblers would negate this somewhat. A legal coorporation could attack these closed systems, not just hackers in their basement.
There you have just described a way to make money. Provide a service that allows people to find what they want.
I suspect the bridge from that POV would be absolutely enormous and any normal camera lens would show only a small piece of it.
Still at D2. Not sure who else you know. Doug Roble is the only other long-term person still in the software dept.
The professional equipment does not have SCMS. So it is quite possible that copy protection is the explanation for the consumer equipment failure, while the machines that lacked it succeeded.
For the 400:1 contrast ratio between the brightest white and black screen of a typical CRT, 8 bits are enough, if they are distributed in a gamma curve such as the sRGB standard, so the black samples are closer together. The eye is quite incapable of seeing the resulting steps, unless large areas of two colors are adjacent. This can be solved by correctly dithering the image to 8 bits when rendering, or by adding noise if the data has been posterized already.
If they go to more bits I would like to see the maximum brightness increased by about 4 times and half the additional range of numbers used to represent colors in that brighter area. The other half of the numbers could be put between the existing brightnesses.
I very much believe no more than 10 bits are necessary, if correctly distributed. Cineon files used for scanning film have a good deal more range than real film and use 10 bits in a logarithmic representation, each number represents the 1.002 times brighter than the previous number.
Converting 8 bit RGB to 8 bit YUV and back is very lossy. The losses are when the floating point values are rounded to the nearest integer. Dithering can help considerably here. They could encoded the signal uses a non-lossy integer conversion of G, R-G, B-G, or the mpeg encoder could use floating-point inputs, so this is less of a problem.
There are about 3 ways to do anti-aliasing:
The very expensive way is to examine the actual paths you are rendering, how they intersect the pixels, and calculating the actual coverage of the pixels directly with math. This is probably what the original poster meant by "floating point". This is easy for infinitely long straight lines but very difficult for any other shape to do correctly.
A less expensive way is subpixel sampling, which is to use the normal black & white algorithim to render the letter about 4 times larger and then use 16 pixels (or sometimes weighted overlapping areas for better quality) to calculate the resulting gray from how many pixels are filled in. This can be done by hardware today and I believe is what is used by Quartz, the older Mac AntiAliasing, the new Windows AntiAliasing, and by Xrender for AntiAliasing. Note that some algorithims do the summation at the same time they calculate the subpixels, so there never is any "high resolution bitmap" in memory, but this does not change the basic algorithim.
The third way is to render at normal size and guess by looking at adjacent pixels. This is what Windows "Font Smoothing" did, I believe. A variation on it (producing shapes rather than grayscales) was used by early Macintoshes to render bitmaps onto higher-resolution printers. The primary advantage of this scheme is that it is fast, but otherwise it sucks.
ClearType is subpixel sampling with some multliple of 3 horizontally (not necessaryilly 1x3 as many people think, doing a higher resolution would result in better antialaiasing). These samples are then weighted-summed down to an image with 3 "subpixels" horizontally and one vertically. This is followed by a step I call "error diffusion" which is the clever part, to change the image by adding or subtracting some subpixels so the total amount or red, green, and blue are equal.
Okay, everybody, got it? "subpixel sampling" was used before Bill Gates first saw a computer, incidentally. It is NOT a MicroSoft invention, so stop making fools of yourselves.
The projectors in use right now are 1280 wide and 1024 tall, and produce a 4/3 aspect image. This is projected through a panavision-style lens to stretch it horizontally. The reason the projectors are this resolution is they are designed for coorporate boardrooms to show PowerPoint presentations. I believe the manufacturers are working on new devices that are designed for cinema and are HDTV resolution.
Not sure if even maximum HDTV resolution is good enough, most digital effects for 35mm are done at 2048 wide and about 1108 tall, though some are done at 1828 by about 988 tall. Lots of people claim this is not good enough and 4096 wide is needed to accurately represent 35mm film.
The virus on Windows could modify the Linux partition so it can aquire the rights to modify the Windows partition.
Absolutely! A lot of the libraries and kludges being written for both Unix and Windows are to implement hierarchies of data in files, because individual files are too slow or have too much overhead. This needs to be fixed and we would be much better off of the effort going into designing the next mail went into designing a filesystem that allowed the "obvious" way to store mail to work.
One unfortunate fact of NeWS is that too many people thought it's purpose was to preview PostScript before printing it, which is all DPS is useful for. That, and Sun's stupidity at not giving it away for the same price as X11, killed it.
I think in fact you are trying to make a bogus example to show that the GPL won't work. It works fine.
This sort of mistake could have been avoided if they had open-sourced the alogirithm (though not the keys). I think somebody would have analyzed it and pointed out the defect.
Then they could have stopped that one key.
However I'm not sure if the plan, even if correctly implemented, is all that good. If a key is compromised and they stop using it, they prevent not only the programs with that key, but also any players that use that key. Forcing everybody who owns such a player to buy a new one may not be the best public relations, and I would expect some DVD publishers to just give up and even advertise their disks "works on older Kenwood DVD players" (or whatever was compromised). Possibly even the publishers have signed contracts saying they won't do this, but I still see an enormous public-relations backlash.
Even worse is the insistance of all new X window managers to copy this foul "click raises" behavior.
A huge breakthrough would be to ONLY RAISE THE WINDOW WHEN THE USER CLICKS ON THE TITLE. In particular stop raising it on clicks, and don't raise it when a child window is raised! If these simple changes were done we could have far better user interfaces with multiple overlapping windows than the crap MicroSoft's stupid decisions have forced us into.
Actually what you propose is quite common and can be done with the GPL. It is called "dual licensing", and Qt is probably the best-known example. You can use Qt in open-source code for free, but if you want to distribute closed-source code you have to pay for a different license.
If they have any qualms about putting out enough information to write an open-source driver for their card, then they will be cracked. Any "secret" in the driver or OS means you are relying on security through obscurity will fail.
In case you don't understand how this works, imagine that the driver interface is like the interface between your remote control and the cable box. Completely disassembling the remote control and reverse engineering it would not let you get any more stations than you already do. And they have no qualms about copying the signals to those reprogrammable remote controls.
So in some ways this is not too bad: Either Linux will be supported, or the system will be cracked. However I don't expect them to be as smart as this and Linux will be outlawed and nothing will be done to stop piracy.