Ha ha funny. When do you run two OpenGL apps at once? No-one in their right mind does. (Unless you like things going at half the fps.) Second, yes, locking could be a problem when using multiple threads, but A. Mutliple threads aren't used often in Linux, and B. BeOS has showing that very efficient locking can be done. And under something like BeOS, where multiple threads using GL might be a problem, in the event that it DID lock, you could just restart the OpenGL server. So A. You normally don't have a problem with multiple OpenGL clients, or B. You are running an OS that has multiple GL clients, but can manage the locking correctly. And I wouldn't critisize Windows until one particualr OS, which shall remain nameless, can outperform it in OpenGL.
Programmers are such grand jackasses. Just becuase one does not use a computer for programming does not mean that they are not computer nerds/geeks. I have known people were were brillient programmers, taking college CS classes in highschool, etc, who thought that the difference between SCSI3 and UDMA drives was that UDMA transferred at 33MB/sec and SCSI at 40MB/sec. He didn't know the RAM limit of the PPro, didn't know what a system chipset is, etc. One would call him a programming nerd, but certainly not a computer nerd, no? Until a few years ago, I used the computer only for graphics and web page, not programming. Yet I could beat any programmer I know when it came to knowledge about the system. Was I or was I not a computer nerd? Thus not all programmers are computer nerds, and not all computer nerds are programmers.
While I don't mean to come off as a troll, I would like throw my opinion into the ring. I think that this whole approach of seperate projects for major OS components is the wrong idea. I know seperate projects is Unixish, but there is a reason why Unix did not make it to the home market. If we just emulate Unix, Linux will end up being a Unix. Something like windowing system should not be its own project with half the system RAM devoted to it along with 40MB+ of code. It should be a collection of clean, fast, low-level libraries tightly integrated with the kernel and other services. I think the whole problem with things such as X and even Berlin, is that they develop it as a application instead of as part of the OS. Also, so many services should not be built into the graphics system. At the moment, X is even worse than the GDI. An idea would be to make a multi-threaded graphics/windowing library that interfaces directly with the kernel. Have this library support client programs via different threads. Secondly, have GUI services as entirely seperate services independant of the GUI itself. For example, the kernel would handle low level details, while the graphics system would interface directly with it and the graphics driver to do low-level graphics. Then the windowing system would interface with the graphics system to do drawing. Or for more performance, pull drawing and windowing into one library. This windowing library would handle the bare minimum needed to draw windows and text, and images. Then higher level services such as font conversion, graphics conversion, etc, would be handled by another library, kind of like glibc. Even higher level things such as applications frameworks and object embedding would be handle by still other services. Thus the need for a "desktop" manager dissapears. Also, bloat is kept out of the lower levels of the system. (ehmm, X, cough...) There is no need for so many projects to be dedicated to doing what should really be a simple and low-level job. You don't see mutliple projects for the ide drivers do you? And this seperate project stuff DOES lead to bloat. What is KDE? Is it a window manager? A service that offers embedding functions? And application framework? This could be implemented in other areas as well. One place where windows has the right idea, is in drivers. Drivers should handle all tasks needed to make the device work, and should have a standerdized interface into the system. No more of the wheel program needed to use the wheel on the intellimouse. I realize that this would probably be a long term project, but in the end, graphics performance will demand low OS tax. The applications should use the most processor time and memory, not the OS. And yes that does sound a lot like Windows and BeOS. Thats because it IS a lot like Windows and BeOS? But think about it, shouldn't thousands of hackers really be able to make a graphics system outperform the GDI? (Graphics Device Interface, for those non Win32 programmers out there.)
Apple troll. (Insanely great?) The PPC FPU arch is crappy in the 603/G3 series, and still not as fast as Alpha in the G4 series. G4 has altivec, but Alpha has VIS (I think.)
Can I get one of those Suns for the same price as my "peecee"? Jackass. Quit trolling, if we could afford "real computers" do you think there would be any reason for using "peecees?" PC computing is all about getting as much performance as you can from what you have. Second, your "peecee" thing gives you away, even though you are an AC.
What do you mean there is no documentation to Windows? I program DirectX and OpenGL and Win32 everyday and I can tell you, that there is tons of documentation. No details on how functions work, (but of course you shouldn't need those details, its called maitaining a good API.) but every function you could possibly need has a very good explaination. Every possible option in the structure is documented. DirectDraw alone has 700 pages of documentation. DirectX in its entirity has about 1500 pages of docs, and the rest of Win32 has another few (2-7) thousand more. Example the docs for GetDeviceCaps. GetDeviceCaps The GetDeviceCaps function retrieves device-specific information about a specified device.
int GetDeviceCaps( HDC hdc,// handle to the device context int nIndex// index of capability to query );
Parameters hdc Handle to the device context. nIndex Specifies the item to return. This parameter can be one of the following values. Index Meaning DRIVERVERSION The device driver version. TECHNOLOGY Device technology. It can be any one of the following values. DT_PLOTTER Vector plotter DT_RASDISPLAY Raster display DT_RASPRINTER Raster printer DT_RASCAMERA Raster camera DT_CHARSTREAM Character stream DT_METAFILE Metafile DT_DISPFILE Display file If the hdc parameter identifies the device context of an enhanced metafile, the device technology is that of the referenced device as given to the CreateEnhMetaFile function. To determine whether it is an enhanced metafile device context, use the GetObjectType function. HORZSIZE Width, in millimeters, of the physical screen. VERTSIZE Height, in millimeters, of the physical screen. HORZRES Width, in pixels, of the screen. VERTRES Height, in raster lines, of the screen. LOGPIXELSX Number of pixels per logical inch along the screen width. In a system with multiple display monitors, this value is the same for all monitors. LOGPIXELSY Number of pixels per logical inch along the screen height. In a system with multiple display monitors, this value is the same for all monitors. BITSPIXEL Number of adjacent color bits for each pixel. PLANES Number of color planes. NUMBRUSHES Number of device-specific brushes. NUMPENS Number of device-specific pens. NUMFONTS Number of device-specific fonts. NUMCOLORS Number of entries in the device's color table, if the device has a color depth of no more than 8 bits per pixel. For devices with greater color depths, -1 is returned. ASPECTX Relative width of a device pixel used for line drawing. ASPECTY Relative height of a device pixel used for line drawing. ASPECTXY Diagonal width of the device pixel used for line drawing. PDEVICESIZE Reserved. CLIPCAPS Flag that indicates the clipping capabilities of the device. If the device can clip to a rectangle, it is 1. Otherwise, it is 0. SIZEPALETTE Number of entries in the system palette. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows. NUMRESERVED Number of reserved entries in the system palette. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows. COLORRES Actual color resolution of the device, in bits per pixel. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows. PHYSICALWIDTH For printing devices: the width of the physical page, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper has a physical width value of 5100 device units. Note that the physical page is almost always greater than the printable area of the page, and never smaller. PHYSICALHEIGHT For printing devices: the height of the physical page, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper has a physical height value of 6600 device units. Note that the physical page is almost always greater than the printable area of the page, and never smaller. PHYSICALOFFSETX For printing devices: the distance from the left edge of the physical page to the left edge of the printable area, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper, that cannot print on the leftmost 0.25" of paper, has a horizontal physical offset of 150 device units. PHYSICALOFFSETY For printing devices: the distance from the top edge of the physical page to the top edge of the printable area, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper, that cannot print on the topmost 0.5" of paper, has a vertical physical offset of 300 device units. VREFRESH Windows NT: For display devices: the current vertical refresh rate of the device, in cycles per second (Hz). A vertical refresh rate value of 0 or 1 represents the display hardware's default refresh rate. This default rate is typically set by switches on a display card or computer motherboard, or by a configuration program that does not use Win32 display functions such as ChangeDisplaySettings.
DESKTOPHORZRES Windows NT: Width, in pixels, of the virtual desktop. This value may be larger than HORZRES if the device supports a virtual desktop or multiple displays. DESKTOPVERTRES Windows NT: Height, in pixels, of the virtual desktop. This value may be larger than VERTRES if the device supports a virtual desktop or multiple displays. SCALINGFACTORX Scaling factor for the x-axis of the printer. SCALINGFACTORY Scaling factor for the y-axis of the printer. BLTALIGNMENT Windows NT: Preferred horizontal drawing alignment, expressed as a multiple of pixels. For best drawing performance, windows should be horizontally aligned to a multiple of this value. A value of zero indicates that the device is accelerated, and any alignment may be used. SHADEBLENDCAPS Windows 98, Windows NT 5.0 and later: Value that indicates the shading and blending capabilities of the device. SB_CONST_ALPHA Handles the SourceConstantAlpha member of the BLENDFUNCTION structure, which is referenced by the blendFunction parameter of the AlphaBlend function. SB_GRAD_RECT Capable of doing GradientFill rectangles. SB_GRAD_TRI Capable of doing GradientFill triangles. SB_NONE Device does not support any of these capabilities. SB_PIXEL_ALPHA Capable of handling per-pixel alpha in AlphaBlend. SB_PREMULT_ALPHA Capable of handling premultiplied alpha in AlphaBlend. RASTERCAPS Value that indicates the raster capabilities of the device, as shown in the following table: RC_BANDING Requires banding support. RC_BITBLT Capable of transferring bitmaps. RC_BITMAP64 Capable of supporting bitmaps larger than 64K. RC_DI_BITMAP Capable of supporting the SetDIBits and GetDIBits functions. RC_DIBTODEV Capable of supporting the SetDIBitsToDevice function. RC_FLOODFILL Capable of performing flood fills. RC_GDI20_OUTPUT Capable of supporting features of 16-bit Windows 2.0. RC_PALETTE Specifies a palette-based device. RC_SCALING Capable of scaling. RC_STRETCHBLT Capable of performing the StretchBlt function. RC_STRETCHDIB Capable of performing the StretchDIBits function. CURVECAPS Value that indicates the curve capabilities of the device, as shown in the following table: CC_NONE Device does not support curves. CC_CHORD Device can draw chord arcs. CC_CIRCLES Device can draw circles. CC_ELLIPSES Device can draw ellipses. CC_INTERIORS Device can draw interiors. CC_PIE Device can draw pie wedges. CC_ROUNDRECT Device can draw rounded rectangles. CC_STYLED Device can draw styled borders. CC_WIDE Device can draw wide borders. CC_WIDESTYLED Device can draw borders that are wide and styled. LINECAPS Value that indicates the line capabilities of the device, as shown in the following table: LC_NONE Device does not support lines. LC_INTERIORS Device can draw interiors. LC_MARKER Device can draw a marker. LC_POLYLINE Device can draw a polyline. LC_POLYMARKER Device can draw multiple markers. LC_STYLED Device can draw styled lines. LC_WIDE Device can draw wide lines. LC_WIDESTYLED Device can draw lines that are wide and styled. POLYGONALCAPS Value that indicates the polygon capabilities of the device, as shown in the following table: PC_NONE Device does not support polygons. PC_INTERIORS Device can draw interiors. PC_POLYGON Device can draw alternate-fill polygons. PC_RECTANGLE Device can draw rectangles. PC_SCANLINE Device can draw a single scanline. PC_STYLED Device can draw styled borders. PC_WIDE Device can draw wide borders. PC_WIDESTYLED Device can draw borders that are wide and styled. PC_WINDPOLYGON Device can draw winding-fill polygons. TEXTCAPS Value that indicates the text capabilities of the device, as shown in the following table: TC_OP_CHARACTER Device is capable of character output precision. TC_OP_STROKE Device is capable of stroke output precision. TC_CP_STROKE Device is capable of stroke clip precision. TC_CR_90 Device is capable of 90-degree character rotation. TC_CR_ANY Device is capable of any character rotation. TC_SF_X_YINDEP Device can scale independently in the x- and y-directions. TC_SA_DOUBLE Device is capable of doubled character for scaling. TC_SA_INTEGER Device uses integer multiples only for character scaling. TC_SA_CONTIN Device uses any multiples for exact character scaling. TC_EA_DOUBLE Device can draw double-weight characters. TC_IA_ABLE Device can italicize. TC_UA_ABLE Device can underline. TC_SO_ABLE Device can draw strikeouts. TC_RA_ABLE Device can draw raster fonts. TC_VA_ABLE Device can draw vector fonts. TC_RESERVED Reserved; must be zero. TC_SCROLLBLT Device cannot scroll using a bit-block transfer. Note that this meaning may be the opposite of what you expect.
Return Values The return value specifies the value of the desired item.
Remarks GetDeviceCaps provides the following six indices in place of printer escapes.
Windows CE: Windows CE does not support the following values for the nIndex parameter:
VREFRESH
DESKTOPHORZRES
DESKTOPVERTRES
BLTALIGNMENT
Windows CE version 1.0 does not support the following values for the nIndex parameter:
PHYSICALWIDTH
PHYSICALHEIGHT
PHYSICALOFFSETX
PHYSICALOFFSETY
QuickInfo Windows NT: Requires version 3.1 or later. Windows: Requires Windows 95 or later. Windows CE: Requires version 1.0 or later. Header: Declared in wingdi.h. Import Library: Use gdi32.lib.
See Also Device Contexts Overview, Device Context Functions, CreateEnhMetaFile, CreateIC, DeviceCapabilities, GetDIBits, GetObjectType, SetDIBits, SetDIBitsToDevice, StretchBlt, StretchDIBits
I assume that you are serious about that statement, which allows me to put you down with a clean consience. First. Windows has better HW acceleration that ANY OS on intel. Beats BeOS too (but the graphics card makers don't speed a huge amount of time tweeking alternative OS code now do the? Look for BeOS to whoop some HW accellerated ass since I think they will code a few good drivers instead of nVidia family and you have 50% or more of the market right there.) But I digress. SGI just plain has better hardware. I doubt even the new nVida GPU will stand up to one of those infinate reality monster cards in SGIs. Second, Blender is crap. It has the most confusing interface (what hotkeys only!) and crappy layout of any 3D renderer I have worked wiht. (MAX, Truespace, Pixel3D, etc.) When compared to MAX or Truespace it gets its ass kicked. Second, GIMP is still nowhere near photoshop, and the buttons aren't in color. Third, well you could render titanic on BSD or anything that doesn't crash every few minutes. If you are talking about modleing, that was done on Windows NT workstations running Alphas. Lastly, linux doesn't even have a full open GL library, how could it have prefected it? (Mesa is not fully GL complient, not only officialy, it lacks some features in 1.2) Addendum. Even this xIG thing is only GL 1.1.1, the world has moved on to 1.2 if you hadn't noticed!
I think it would be a lot easier if you make the drivers pluggable into XFree, thus companies can publish binary only drivers and Linux hardware support would not be a problem. I understand wanting to be able to hack your userspace apps, and maybe part of the kernel, but think about it, even if you have the sources to the drivers, why would you hack it considering that nVidia knows a hell of a lot more about the hardware than you do? Don't say bug fixing cuz nVidia drivers are rock solid on windows9x (quite a feat that is too.)
Although you have a good point, (personally I define OS that provides services to other applications. No one would want to run part of the OS by itself. Ie. Winsock would be considered part of the OS, but not AOL?) I think what the meaning of the original author was that 3Com pulled some OS code into the GUI, or that the OS and GUI were not seperate at all, thus if you wanted to replace the GUI, you would have to rewrite the code that had been pulled into it.
Actually, in the process of writing that shell you would have to write a lot of kernel code as well. I think what the other guy was trying to say is that the Palm GUI does NOT talk to something else, it talks directly to hardware, so if you wanter to replace it with a shell, you would have to rewrite a bunch of what the gui was doing besides interface.
Thats what you are doing! Unless your Win98 directory is coppied to your hard drive, Windows only installs drivers for stuff you have. (Why do you think they ask for the Windows CD whenever you install something?)
Ha ha funny. IE is just a user space applications that does double duty as the shell. And its a pretty damn good idea too, becuase forward and back buttons on explorer make a lot of sense. I find myself wishing that Netpositive would replace tracker. (Just for file browsing though.) And remember, until the Linux GUI is smaller than the Windows GUI (or the linux kernel) linux people are in no position to poke fun at IE.
Guess what I makes more sense! Since most people are right handed, it is easier for them to do things on the RIGHT HAND SIDE! Thats why scroll bars are on the right too! Forward slash has stupid though, on most keyboard \ is wayyy up there by the enter key.
Oh, a lowball joke at us GUI users huh. Right clicking and hitting new takes just as little time as typing in mkdir/boot/apps/snes9x or what ever. Sure you may have a slight edge in doing multiple repetitive things, or quickly getting to directories, but we have edges in a lot of things. To make a link from a buried down directory to the desktop, in BeOS it takes me 2 clicks and 2 mouse swipes. In Terminal I have to type the command, followed by the directory, followed by the name of the desktop directory. Secondly, if it takes clicking through 5 menues, then it is a badly designed gui. Even windows rarly has more than a 2 menu depth for most functions. Second, hotkeys take away a lot of the edge of using the console. Lastly, unless you are using X or Win9x, then loading up menus is not a problem. (ie. as long as you are using BeOS or photon.) A gui is just as part of the OS as a console is, if not more so. Depends on the OS. Windows9x has a gui that is part of the OS, and a console that is not. As does Be. In linux, neither are part of the OS. (although for all purposes, Bash is more or less part of the OS.) X is very far removed from the OS. (As a side note compare the graphics performances of said systems and tell me if you see a pattern.) Lastly, lets you and me have a match. I will use the GUI based 3D max, and you can use PovRay. Lets see who can make a complex scene first. Or you can uses Lynx without a mouse, and I can use IE and lets see who gets to their webpage first. Or you can use EMacs and GCC, and I'll use Visual C++ and lets see who can write their project first. I think someone once said on Slashdot that you should use the right tool for each job.
Question? Why not extend C++ with a bunch of fast lowlevel graphics and GUI libraries (kinda like STL) and have the OS makers maintian the back end code. Like I can cout on everything from an NT machine to a Vax, to Be (run the app from terminal)and it works. Of course the backend code is not the same, but that doesn't matter. Speed would not suffer. It would be just like graphics drivers, they all have a standard interface, but they keep getting faster because companies want theirs to stand out. Then make super optimized compilers for each platform (VC++ is damn close to as good as it gets on x86. I think Intel's is the fastest though but only by a it.) So yea would have to recompile the app for each platform, but how long does that take?
Ohhh this is a troll if a ever saw one. What age are you living in. There is a reason your BeBox is slow. Its like 4 years OLD. (Trust me, in their day BeBoxen were never considered slow.) Second, every release since DR 8 has been rock solid. I've had a grand total of three chrashes in BeOS. Twice due to a bug in the AWE64 driver that crashed the computer if you tried to record and play at the same time. And one when I killed the app server. But they have programs that resurect it now. Thats right. You can kill the app server and bring it back up without rebooting. Second, groups and users are only partially implemented to make the Unix utilities happy. At its base, multiuser would sully the OS. (Maybe login profiles instead? What idiot tries to use a workstation with two people for real work. If you just need basic stuff, you can always telnet in.) Third. I think BeOS used some lilo code in its boot manager around the preview releases. It was taken out before R3.2
Hey, I'm a geek too, and I love BeOS. (BTW Only on Slashdot do people pride themselves for being geeks.) Maybe its just me, but the whole pervasive multi-threading, media oriented, fast and light concept just excites me.
Becuase 3DNow support with nVidia is traditionally behind Intel support. 3Dnow came out much later for TNT than for other cards. + Athlon is faster with TNT 2 so mightn't it be more likly that SSE is the culprit?
Slashdot Mirror
Ha ha funny. When do you run two OpenGL apps at once? No-one in their right mind does. (Unless you like things going at half the fps.) Second, yes, locking could be a problem when using multiple threads, but A. Mutliple threads aren't used often in Linux, and B. BeOS has showing that very efficient locking can be done. And under something like BeOS, where multiple threads using GL might be a problem, in the event that it DID lock, you could just restart the OpenGL server. So A. You normally don't have a problem with multiple OpenGL clients, or B. You are running an OS that has multiple GL clients, but can manage the locking correctly. And I wouldn't critisize Windows until one particualr OS, which shall remain nameless, can outperform it in OpenGL.
Programmers are such grand jackasses. Just becuase one does not use a computer for programming does not mean that they are not computer nerds/geeks. I have known people were were brillient programmers, taking college CS classes in highschool, etc, who thought that the difference between SCSI3 and UDMA drives was that UDMA transferred at 33MB/sec and SCSI at 40MB/sec. He didn't know the RAM limit of the PPro, didn't know what a system chipset is, etc. One would call him a programming nerd, but certainly not a computer nerd, no? Until a few years ago, I used the computer only for graphics and web page, not programming. Yet I could beat any programmer I know when it came to knowledge about the system. Was I or was I not a computer nerd? Thus not all programmers are computer nerds, and not all computer nerds are programmers.
While I don't mean to come off as a troll, I would like throw my opinion into the ring. I think that this whole approach of seperate projects for major OS components is the wrong idea. I know seperate projects is Unixish, but there is a reason why Unix did not make it to the home market. If we just emulate Unix, Linux will end up being a Unix. Something like windowing system should not be its own project with half the system RAM devoted to it along with 40MB+ of code. It should be a collection of clean, fast, low-level libraries tightly integrated with the kernel and other services. I think the whole problem with things such as X and even Berlin, is that they develop it as a application instead of as part of the OS. Also, so many services should not be built into the graphics system. At the moment, X is even worse than the GDI. An idea would be to make a multi-threaded graphics/windowing library that interfaces directly with the kernel. Have this library support client programs via different threads. Secondly, have GUI services as entirely seperate services independant of the GUI itself. For example, the kernel would handle low level details, while the graphics system would interface directly with it and the graphics driver to do low-level graphics. Then the windowing system would interface with the graphics system to do drawing. Or for more performance, pull drawing and windowing into one library. This windowing library would handle the bare minimum needed to draw windows and text, and images. Then higher level services such as font conversion, graphics conversion, etc, would be handled by another library, kind of like glibc. Even higher level things such as applications frameworks and object embedding would be handle by still other services. Thus the need for a "desktop" manager dissapears. Also, bloat is kept out of the lower levels of the system. (ehmm, X, cough...) There is no need for so many projects to be dedicated to doing what should really be a simple and low-level job. You don't see mutliple projects for the ide drivers do you?
And this seperate project stuff DOES lead to bloat. What is KDE? Is it a window manager? A service that offers embedding functions? And application framework? This could be implemented in other areas as well. One place where windows has the right idea, is in drivers. Drivers should handle all tasks needed to make the device work, and should have a standerdized interface into the system. No more of the wheel program needed to use the wheel on the intellimouse. I realize that this would probably be a long term project, but in the end, graphics performance will demand low OS tax. The applications should use the most processor time and memory, not the OS. And yes that does sound a lot like Windows and BeOS. Thats because it IS a lot like Windows and BeOS? But think about it, shouldn't thousands of hackers really be able to make a graphics system outperform the GDI? (Graphics Device Interface, for those non Win32 programmers out there.)
Apple troll. (Insanely great?) The PPC FPU arch is crappy in the 603/G3 series, and still not as fast as Alpha in the G4 series. G4 has altivec, but Alpha has VIS (I think.)
Can I get one of those Suns for the same price as my "peecee"? Jackass. Quit trolling, if we could afford "real computers" do you think there would be any reason for using "peecees?" PC computing is all about getting as much performance as you can from what you have. Second, your "peecee" thing gives you away, even though you are an AC.
Hey, you forgot BeOS!
What do you mean there is no documentation to Windows? I program DirectX and OpenGL and Win32 everyday and I can tell you, that there is tons of documentation. No details on how functions work, (but of course you shouldn't need those details, its called maitaining a good API.) but every function you could possibly need has a very good explaination. Every possible option in the structure is documented. DirectDraw alone has 700 pages of documentation. DirectX in its entirity has about 1500 pages of docs, and the rest of Win32 has another few (2-7) thousand more.
// handle to the device context // index of capability to query
Example the docs for GetDeviceCaps.
GetDeviceCaps
The GetDeviceCaps function retrieves device-specific information about a specified device.
int GetDeviceCaps(
HDC hdc,
int nIndex
);
Parameters
hdc
Handle to the device context.
nIndex
Specifies the item to return. This parameter can be one of the following values. Index Meaning
DRIVERVERSION The device driver version.
TECHNOLOGY Device technology. It can be any one of the following values.
DT_PLOTTER Vector plotter
DT_RASDISPLAY Raster display
DT_RASPRINTER Raster printer
DT_RASCAMERA Raster camera
DT_CHARSTREAM Character stream
DT_METAFILE Metafile
DT_DISPFILE Display file
If the hdc parameter identifies the device context of an enhanced metafile, the device technology is that of the referenced device as given to the CreateEnhMetaFile function. To determine whether it is an enhanced metafile device context, use the GetObjectType function.
HORZSIZE Width, in millimeters, of the physical screen.
VERTSIZE Height, in millimeters, of the physical screen.
HORZRES Width, in pixels, of the screen.
VERTRES Height, in raster lines, of the screen.
LOGPIXELSX Number of pixels per logical inch along the screen width. In a system with multiple display monitors, this value is the same for all monitors.
LOGPIXELSY Number of pixels per logical inch along the screen height. In a system with multiple display monitors, this value is the same for all monitors.
BITSPIXEL Number of adjacent color bits for each pixel.
PLANES Number of color planes.
NUMBRUSHES Number of device-specific brushes.
NUMPENS Number of device-specific pens.
NUMFONTS Number of device-specific fonts.
NUMCOLORS Number of entries in the device's color table, if the device has a color depth of no more than 8 bits per pixel. For devices with greater color depths, -1 is returned.
ASPECTX Relative width of a device pixel used for line drawing.
ASPECTY Relative height of a device pixel used for line drawing.
ASPECTXY Diagonal width of the device pixel used for line drawing.
PDEVICESIZE Reserved.
CLIPCAPS Flag that indicates the clipping capabilities of the device. If the device can clip to a rectangle, it is 1. Otherwise, it is 0.
SIZEPALETTE Number of entries in the system palette. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows.
NUMRESERVED Number of reserved entries in the system palette. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows.
COLORRES Actual color resolution of the device, in bits per pixel. This index is valid only if the device driver sets the RC_PALETTE bit in the RASTERCAPS index and is available only if the driver is compatible with 16-bit Windows.
PHYSICALWIDTH For printing devices: the width of the physical page, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper has a physical width value of 5100 device units. Note that the physical page is almost always greater than the printable area of the page, and never smaller.
PHYSICALHEIGHT For printing devices: the height of the physical page, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper has a physical height value of 6600 device units. Note that the physical page is almost always greater than the printable area of the page, and never smaller.
PHYSICALOFFSETX For printing devices: the distance from the left edge of the physical page to the left edge of the printable area, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper, that cannot print on the leftmost 0.25" of paper, has a horizontal physical offset of 150 device units.
PHYSICALOFFSETY For printing devices: the distance from the top edge of the physical page to the top edge of the printable area, in device units. For example, a printer set to print at 600 dpi on 8.5"x11" paper, that cannot print on the topmost 0.5" of paper, has a vertical physical offset of 300 device units.
VREFRESH Windows NT: For display devices: the current vertical refresh rate of the device, in cycles per second (Hz).
A vertical refresh rate value of 0 or 1 represents the display hardware's default refresh rate. This default rate is typically set by switches on a display card or computer motherboard, or by a configuration program that does not use Win32 display functions such as ChangeDisplaySettings.
DESKTOPHORZRES Windows NT: Width, in pixels, of the virtual desktop. This value may be larger than HORZRES if the device supports a virtual desktop or multiple displays.
DESKTOPVERTRES Windows NT: Height, in pixels, of the virtual desktop. This value may be larger than VERTRES if the device supports a virtual desktop or multiple displays.
SCALINGFACTORX Scaling factor for the x-axis of the printer.
SCALINGFACTORY Scaling factor for the y-axis of the printer.
BLTALIGNMENT Windows NT: Preferred horizontal drawing alignment, expressed as a multiple of pixels. For best drawing performance, windows should be horizontally aligned to a multiple of this value. A value of zero indicates that the device is accelerated, and any alignment may be used.
SHADEBLENDCAPS Windows 98, Windows NT 5.0 and later: Value that indicates the shading and blending capabilities of the device.
SB_CONST_ALPHA Handles the SourceConstantAlpha member of the BLENDFUNCTION structure, which is referenced by the blendFunction parameter of the AlphaBlend function.
SB_GRAD_RECT Capable of doing GradientFill rectangles.
SB_GRAD_TRI Capable of doing GradientFill triangles.
SB_NONE Device does not support any of these capabilities.
SB_PIXEL_ALPHA Capable of handling per-pixel alpha in AlphaBlend.
SB_PREMULT_ALPHA Capable of handling premultiplied alpha in AlphaBlend.
RASTERCAPS Value that indicates the raster capabilities of the device, as shown in the following table:
RC_BANDING Requires banding support.
RC_BITBLT Capable of transferring bitmaps.
RC_BITMAP64 Capable of supporting bitmaps larger than 64K.
RC_DI_BITMAP Capable of supporting the SetDIBits and GetDIBits functions.
RC_DIBTODEV Capable of supporting the SetDIBitsToDevice function.
RC_FLOODFILL Capable of performing flood fills.
RC_GDI20_OUTPUT Capable of supporting features of 16-bit Windows 2.0.
RC_PALETTE Specifies a palette-based device.
RC_SCALING Capable of scaling.
RC_STRETCHBLT Capable of performing the StretchBlt function.
RC_STRETCHDIB Capable of performing the StretchDIBits function.
CURVECAPS Value that indicates the curve capabilities of the device, as shown in the following table:
CC_NONE Device does not support curves.
CC_CHORD Device can draw chord arcs.
CC_CIRCLES Device can draw circles.
CC_ELLIPSES Device can draw ellipses.
CC_INTERIORS Device can draw interiors.
CC_PIE Device can draw pie wedges.
CC_ROUNDRECT Device can draw rounded rectangles.
CC_STYLED Device can draw styled borders.
CC_WIDE Device can draw wide borders.
CC_WIDESTYLED Device can draw borders that are wide and styled.
LINECAPS Value that indicates the line capabilities of the device, as shown in the following table:
LC_NONE Device does not support lines.
LC_INTERIORS Device can draw interiors.
LC_MARKER Device can draw a marker.
LC_POLYLINE Device can draw a polyline.
LC_POLYMARKER Device can draw multiple markers.
LC_STYLED Device can draw styled lines.
LC_WIDE Device can draw wide lines.
LC_WIDESTYLED Device can draw lines that are wide and styled.
POLYGONALCAPS Value that indicates the polygon capabilities of the device, as shown in the following table:
PC_NONE Device does not support polygons.
PC_INTERIORS Device can draw interiors.
PC_POLYGON Device can draw alternate-fill polygons.
PC_RECTANGLE Device can draw rectangles.
PC_SCANLINE Device can draw a single scanline.
PC_STYLED Device can draw styled borders.
PC_WIDE Device can draw wide borders.
PC_WIDESTYLED Device can draw borders that are wide and styled.
PC_WINDPOLYGON Device can draw winding-fill polygons.
TEXTCAPS Value that indicates the text capabilities of the device, as shown in the following table:
TC_OP_CHARACTER Device is capable of character output precision.
TC_OP_STROKE Device is capable of stroke output precision.
TC_CP_STROKE Device is capable of stroke clip precision.
TC_CR_90 Device is capable of 90-degree character rotation.
TC_CR_ANY Device is capable of any character rotation.
TC_SF_X_YINDEP Device can scale independently in the x- and y-directions.
TC_SA_DOUBLE Device is capable of doubled character for scaling.
TC_SA_INTEGER Device uses integer multiples only for character scaling.
TC_SA_CONTIN Device uses any multiples for exact character scaling.
TC_EA_DOUBLE Device can draw double-weight characters.
TC_IA_ABLE Device can italicize.
TC_UA_ABLE Device can underline.
TC_SO_ABLE Device can draw strikeouts.
TC_RA_ABLE Device can draw raster fonts.
TC_VA_ABLE Device can draw vector fonts.
TC_RESERVED Reserved; must be zero.
TC_SCROLLBLT Device cannot scroll using a bit-block transfer. Note that this meaning may be the opposite of what you expect.
Return Values
The return value specifies the value of the desired item.
Remarks
GetDeviceCaps provides the following six indices in place of printer escapes.
Index Printer Escape Replaced
PHYSICALWIDTH GETPHYSPAGESIZE
PHYSICALHEIGHT GETPHYSPAGESIZE
PHYSICALOFFSETX GETPRINTINGOFFSET
PHYSICALOFFSETY GETPHYSICALOFFSET
SCALINGFACTORX GETSCALINGFACTOR
SCALINGFACTORY GETSCALINGFACTOR
Windows CE: Windows CE does not support the following values for the nIndex parameter:
VREFRESH
DESKTOPHORZRES
DESKTOPVERTRES
BLTALIGNMENT
Windows CE version 1.0 does not support the following values for the nIndex parameter:
PHYSICALWIDTH
PHYSICALHEIGHT
PHYSICALOFFSETX
PHYSICALOFFSETY
QuickInfo
Windows NT: Requires version 3.1 or later.
Windows: Requires Windows 95 or later.
Windows CE: Requires version 1.0 or later.
Header: Declared in wingdi.h.
Import Library: Use gdi32.lib.
See Also
Device Contexts Overview, Device Context Functions, CreateEnhMetaFile, CreateIC, DeviceCapabilities, GetDIBits, GetObjectType, SetDIBits, SetDIBitsToDevice, StretchBlt, StretchDIBits
What more do you want?
Ha ha funny. When EToys has the volume of ToysR Us, then you can talk.
I assume that you are serious about that statement, which allows me to put you down with a clean consience. First. Windows has better HW acceleration that ANY OS on intel. Beats BeOS too (but the graphics card makers don't speed a huge amount of time tweeking alternative OS code now do the? Look for BeOS to whoop some HW accellerated ass since I think they will code a few good drivers instead of nVidia family and you have 50% or more of the market right there.) But I digress. SGI just plain has better hardware. I doubt even the new nVida GPU will stand up to one of those infinate reality monster cards in SGIs. Second, Blender is crap. It has the most confusing interface (what hotkeys only!) and crappy layout of any 3D renderer I have worked wiht. (MAX, Truespace, Pixel3D, etc.) When compared to MAX or Truespace it gets its ass kicked. Second, GIMP is still nowhere near photoshop, and the buttons aren't in color. Third, well you could render titanic on BSD or anything that doesn't crash every few minutes. If you are talking about modleing, that was done on Windows NT workstations running Alphas. Lastly, linux doesn't even have a full open GL library, how could it have prefected it? (Mesa is not fully GL complient, not only officialy, it lacks some features in 1.2) Addendum. Even this xIG thing is only GL 1.1.1, the world has moved on to 1.2 if you hadn't noticed!
Isn't Xinside the one who started all this DRI stuff for XFree?
I think it would be a lot easier if you make the drivers pluggable into XFree, thus companies can publish binary only drivers and Linux hardware support would not be a problem. I understand wanting to be able to hack your userspace apps, and maybe part of the kernel, but think about it, even if you have the sources to the drivers, why would you hack it considering that nVidia knows a hell of a lot more about the hardware than you do?
Don't say bug fixing cuz nVidia drivers are rock solid on windows9x (quite a feat that is too.)
Is that why even MS has better graphics performance that Linux?
Although you have a good point, (personally I define OS that provides services to other applications. No one would want to run part of the OS by itself. Ie. Winsock would be considered part of the OS, but not AOL?) I think what the meaning of the original author was that 3Com pulled some OS code into the GUI, or that the OS and GUI were not seperate at all, thus if you wanted to replace the GUI, you would have to rewrite the code that had been pulled into it.
Actually, in the process of writing that shell you would have to write a lot of kernel code as well. I think what the other guy was trying to say is that the Palm GUI does NOT talk to something else, it talks directly to hardware, so if you wanter to replace it with a shell, you would have to rewrite a bunch of what the gui was doing besides interface.
Thats what you are doing! Unless your Win98 directory is coppied to your hard drive, Windows only installs drivers for stuff you have. (Why do you think they ask for the Windows CD whenever you install something?)
Ha ha funny. IE is just a user space applications that does double duty as the shell. And its a pretty damn good idea too, becuase forward and back buttons on explorer make a lot of sense. I find myself wishing that Netpositive would replace tracker. (Just for file browsing though.) And remember, until the Linux GUI is smaller than the Windows GUI (or the linux kernel) linux people are in no position to poke fun at IE.
So for Linux 5000 man pages and 50 hours of downloads are part of the OS?
Guess what I makes more sense! Since most people are right handed, it is easier for them to do things on the RIGHT HAND SIDE! Thats why scroll bars are on the right too! Forward slash has stupid though, on most keyboard \ is wayyy up there by the enter key.
Oh, a lowball joke at us GUI users huh. Right clicking and hitting new takes just as little time as typing in mkdir /boot/apps/snes9x or what ever. Sure you may have a slight edge in doing multiple repetitive things, or quickly getting to directories, but we have edges in a lot of things. To make a link from a buried down directory to the desktop, in BeOS it takes me 2 clicks and 2 mouse swipes. In Terminal I have to type the command, followed by the directory, followed by the name of the desktop directory. Secondly, if it takes clicking through 5 menues, then it is a badly designed gui. Even windows rarly has more than a 2 menu depth for most functions. Second, hotkeys take away a lot of the edge of using the console. Lastly, unless you are using X or Win9x, then loading up menus is not a problem. (ie. as long as you are using BeOS or photon.) A gui is just as part of the OS as a console is, if not more so. Depends on the OS. Windows9x has a gui that is part of the OS, and a console that is not. As does Be. In linux, neither are part of the OS. (although for all purposes, Bash is more or less part of the OS.) X is very far removed from the OS. (As a side note compare the graphics performances of said systems and tell me if you see a pattern.) Lastly, lets you and me have a match. I will use the GUI based 3D max, and you can use PovRay. Lets see who can make a complex scene first. Or you can uses Lynx without a mouse, and I can use IE and lets see who gets to their webpage first. Or you can use EMacs and GCC, and I'll use Visual C++ and lets see who can write their project first. I think someone once said on Slashdot that you should use the right tool for each job.
Question? Why not extend C++ with a bunch of fast lowlevel graphics and GUI libraries (kinda like STL) and have the OS makers maintian the back end code. Like I can cout on everything from an NT machine to a Vax, to Be (run the app from terminal)and it works. Of course the backend code is not the same, but that doesn't matter. Speed would not suffer. It would be just like graphics drivers, they all have a standard interface, but they keep getting faster because companies want theirs to stand out. Then make super optimized compilers for each platform (VC++ is damn close to as good as it gets on x86. I think Intel's is the fastest though but only by a it.) So yea would have to recompile the app for each platform, but how long does that take?
Ohhh this is a troll if a ever saw one. What age are you living in. There is a reason your BeBox is slow. Its like 4 years OLD. (Trust me, in their day BeBoxen were never considered slow.) Second, every release since DR 8 has been rock solid. I've had a grand total of three chrashes in BeOS. Twice due to a bug in the AWE64 driver that crashed the computer if you tried to record and play at the same time. And one when I killed the app server. But they have programs that resurect it now. Thats right. You can kill the app server and bring it back up without rebooting. Second, groups and users are only partially implemented to make the Unix utilities happy. At its base, multiuser would sully the OS. (Maybe login profiles instead? What idiot tries to use a workstation with two people for real work. If you just need basic stuff, you can always telnet in.) Third. I think BeOS used some lilo code in its boot manager around the preview releases. It was taken out before R3.2
Why the hell was this not moderated down?
Hey, I'm a geek too, and I love BeOS. (BTW Only on Slashdot do people pride themselves for being geeks.) Maybe its just me, but the whole pervasive multi-threading, media oriented, fast and light concept just excites me.
Becuase 3DNow support with nVidia is traditionally behind Intel support. 3Dnow came out much later for TNT than for other cards. + Athlon is faster with TNT 2 so mightn't it be more likly that SSE is the culprit?
Ouch. That does hurt