[JAVA2D] nvidia drivers - pci express running at x1 instead of 16x
Maybe it could be interesting for the java2d team too. Read it as a kind-of warning. Looks like the new 169.21 whql NVidia drivers and above (new betas) have some problems in dealing with the PCIe bus, making it run at 1x instead of 16x. This problem does not affect the previous 163.75 whql driver which runs smoothly at 16x. Is there someone here with the same performance issue ? my config Log (use the NV control panel, click on the system information text): -- NVIDIA System Information report created on: 01/14/2008 09:20:57 System name: MIK [Display] Processor: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2400 MHz) Operating System: Microsoft Windows XP (Service Pack 2) DirectX version: 9.0c GPU processor: GeForce 8600 GTS ForceWare version: 169.28 Memory: 512 MB Video BIOS version: 60.84.41.00.00 IRQ: 16 Bus: PCI Express x1 [Components] nvCpl.cpl 1.5.600.01 NVIDIA Control Panel Applet nvExpBar.dll 1.5.600.01 NVIDIA Control Panel nvCplUI.exe 1.5.600.01 NVIDIA Control Panel nvWSS.dll 6.14.11.6928 NVIDIA Workstation Server nvViTvS.dll 6.14.11.6928 NVIDIA Video and TV Server nvMoblS.dll 6.14.11.6928 NVIDIA Mobile Server NVMCTRAY.DLL 6.14.11.6928 NVIDIA Media Center Library NVOGLNT.DLL 6.14.11.6928 NVIDIA Compatible OpenGL ICD nvDispS.dll 6.14.11.6928 NVIDIA Display Server NVCPL.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver, Version 169.28 NV4_MINI.SYS 6.14.11.6928 NVIDIA Compatible Windows 2000 Miniport Driver, Version 169.28 NV4_DISP.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver, Version 169.28 nvGameS.dll 6.14.11.6928 NVIDIA 3D Settings Server -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Load and display OpenType Fonts
Depends what you mean by OpenType. If you mean specifically the CFF (Postscript outlines) subset of OpenType then JDK doesn't support that. There's an open RFE on this : http://bugs.sun.com/view_bug.do?bug_id=4356282 -phil. [EMAIL PROTECTED] wrote: Hello, I noticed that [i]sun.font.FontManager.getFontsFromPlatform()[/i] does not return OpenType Fonts installed on a System (using Windows XP, SP2, Java 1.6.0_05-ea). Aswell creating new Font objects with OpenType Fonts as name does not work too. Is there any way to load and render Fonts with Graphics2D, or is there any JSR/other library capable of that (as far as my googling skills tell: there isn't)? regards, newcron [Message sent by forum member 'newcron' (newcron)] http://forums.java.net/jive/thread.jspa?messageID=253698 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] nvidia drivers - pci express running at x1 instead of 16x
A little followup: after testing new and beta drivers with no luck, I decided to install a different board: NV7600GT without changing the drivers. The NV7600GT worked very well at x16 speed and the new drivers (169.21) were ok. I removed the NV7600 and installed the NV8600GTX and this time was running at 16x as expected. All ok ? Not completely: the drivers 169.21 for sure give different onscreeen performance, comparing with the previous 163.75. They are roughly 65% slower. Anyway I achieve the same speed when testing in-memory read-write benchmarks: 1.7GB/s write, 1.0GB/s read. For onscreen I mean - compute some graphics (with opengl), make an argb bufferedimage, paint onscreen (jpanel). My guess is that Nvidia changed something in the screen updating code. This is jdk independent: jdk 1.5.x and jdk 1.6.0_04 give the same results. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Area.isRectangular() behaves differently on Area's that are equal. A bug?
This is probably due to the fact that the Area class does not optimize the case of 2 rectangular areas which abut each other top and bottom into a single rectangular area, but it does optimize the horizontal case. The isRectangular() method performs a trivial check for a single outline with 4 sides, not a more exhaustive comparison to the area that the various pieces cover. In the case of a shape that wasn't optimized by the calculations it may not notice that the result is square. Also, its definition of rectangular is specific to an axis aligned rectangle so your 45 degree rotated square polygon would not evaluate as rectangular as per the intent of its implementation, though the spec doesn't quite call this out (unless your definition of rectangle assumes axis alignment which may be true of the Rectangle class, but not of the common English term rectangular). We should probably clarify that in the method comments. The equals() method does perform the more exhaustive comparison/tests that notice that the area is equal when you compare it to its bounds rectangle. Obviously this fails for the 45 degree rotated square polygon that you test so the answers in that case are consistent with the above clarification of the definition of isRectangular()... ...jim [EMAIL PROTECTED] wrote: Hi, Under certain conditions I find the following: [code] Area a, b; (a.equals(b) b.equals(a)) != (a.isRectangular b.isRectangular()) [/code] Is this a bug? Or am I missing something? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Merging sysmem vram
The per-pixel overhead of accessing VRAM would probably be more noticeable than the per-operation overhead of getting the pixels into the pipeline - unless there was a lot of overlap between the sysmem images. With little or no overlap then it might even be faster to blit the component sysmem images rather than a single blit of the framebuffer image - depending on the difference in the number of pixels touched... ...jim [EMAIL PROTECTED] wrote: Yeah well I was being a bit stupid. I wanted to copy all my sysmem images (just plain int[]'s) to the int[] data of one big bufferedimage (the framebuffer). Obviously blitting all those sysmem images individually to vram using a bufferedimage per sysmem image would add more overhead vs one framebuffer blit. But all overlaps between sysmem direct vram blits are lost that way ofcourse... So I guess there's no way around doing one bufferedimage per sysmem image. [Message sent by forum member 'bitshit' (bitshit)] http://forums.java.net/jive/thread.jspa?messageID=253587 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Merging sysmem vram
The per-pixel overhead of accessing VRAM would probably be more noticeable than the per-operation overhead of getting the pixels into the pipeline - unless there was a lot of overlap between the sysmem images. With little or no overlap then it might even be faster to blit the component sysmem images rather than a single blit of the framebuffer image - depending on the difference in the number of pixels touched... How come overlapping sysmem images would descrease performance vs non overlapping sysmem images when doing per image blits? [Message sent by forum member 'bitshit' (bitshit)] http://forums.java.net/jive/thread.jspa?messageID=253855 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Merging sysmem vram
If VRAM is expensive to store per-pixel then the cost you pay to do the blit(s) is dependent on the number of pixels. If you are writing to the same VRAM pixels over and over because the sysmem images overlap then you pay the cost to access pixels that will later be overwritten. By contrast if you blit all of the sysmem images to a temporary memory buffer then the redundant writes to the same pixels will be only at the cost of system memory access which tends to be much faster - later when you copy the temporary buffer to the screen then you only access each VRAM pixel once so there is no wasted or redundant effort with respect to any overlap. What it comes down to is comparing the number of sysmem pixels written by each method and then comparing the costs of writing to VRAM vs. writing to sysmem. If there is little to no overlap in the sysmem images then the answer is a no-brainer since you will write the same or fewer pixels to blit the sysmem images directly to the VRAM than to blit them to a temporary sysmem buffer. If the total number of pixels in the sysmem images is less than the number of pixels in the temporary buffer, then again the cost of doing the blits directly to VRAM will be less because you have fewer pixels to write (even if there is overlap). If there is overlap and the total number of pixels in the sysmem images is larger than the total number of pixels in the temporary buffer, then it depends on the ratios above as to which will be faster... ...jim [EMAIL PROTECTED] wrote: The per-pixel overhead of accessing VRAM would probably be more noticeable than the per-operation overhead of getting the pixels into the pipeline - unless there was a lot of overlap between the sysmem images. With little or no overlap then it might even be faster to blit the component sysmem images rather than a single blit of the framebuffer image - depending on the difference in the number of pixels touched... How come overlapping sysmem images would descrease performance vs non overlapping sysmem images when doing per image blits? [Message sent by forum member 'bitshit' (bitshit)] http://forums.java.net/jive/thread.jspa?messageID=253855 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
