Bug Tracker item #3444605, was opened at 2011-11-28 15:42 Message generated for change (Comment added) made by ragoley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3444605&group_id=254363
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Java viewer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert (ragoley) Assigned to: Brian Hinz (bphinz) Summary: Crashes with Windows 7 x64 and JDK 7 Initial Comment: I have been doing some testing on windows 7 64 bit. It has the 64 bit JDK 7. I get crashes from trying to connect to DRC's 11-23-2011 build of Xvnc for 64 bit linux. I have gotten several different errors. The only one that will reproduce now is: "com.tigervnc.rdr.Exception: Rect too big.". I get this message immediately after keying in my password and clicking ok. This only happens when using tight encoding. The other encoding methods are fine. The other error was from Jzlib complaining about not being able to Deflate data. Not sure why that one will not reproduce like it was earlier. ---------------------------------------------------------------------- >Comment By: Robert (ragoley) Date: 2011-12-08 07:22 Message: I have noticed the performance hit to be most clear with certain custom QT3 based applications. Not sure if this is a jpeg image block that is just more complicated to render or whether it shows part of the java viewer that renders inefficiently. I will continue to do more testing. If possible, I will try to provide a test environment where you can test it yourself with one of the custom apps. ---------------------------------------------------------------------- Comment By: Robert (ragoley) Date: 2011-12-05 11:36 Message: The crashes were fixed in r4820. I have tested it on Windows XP with 1.6, Ubuntu 10.04 with 1.6, OSX 10.6 with 1.6 and Windows 7 with 1.7. I am starting to test the performance changes but am not seeing anything significant over the previous version with my workstation. I will double check on the other environments. A small note would be that I am visually seeing less performance in my Ubuntu environments. That includes the Atom 330 environment and my triple boot iMac. The Ubuntu side of my iMac performs slower than the same machine running under Windows XP or OSX 10.6. Just slightly but it is enough to be noticeable. I will let you know how the Atom 330 test goes. I would say this crash ticket could be closed though. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-12-04 15:16 Message: Robert, r4822 should improve performance for Tight encoding a little bit. However, I cannot reproduce the kind of performance problems that you described previously: <snip> The overall drawing of the screen was also affected. Before with OpenJDK, it would draw lines of small blocks top to bottom from left to right. This applied for the initial screen and for redrawing windows. With the Sun JDK, it is much faster instead drawing in larger lines/block regions at a time. Again, still not fast enough to really use. The last part of the performance was from pointer/mouse response. It was pretty bad on both JDKs. I am sure the Sun one was better but only marginally. I am going to play around with nice, ionice, and CPU pinning to see if I can get better performance from it. The Atom 330 has hyperthreading enabled and the process was hopping between virtual processors quite a bit. </snip> On my Atom 230 system running Linux Mint 11 I find performance to be slow, but certainly usable. For example, I can play streaming videos even for medium desktop sizes without too much chop. Normal desktop activities are fine, no issues at all with pointer responsiveness. All of this was with an equally slow server running Xvnc (RHEL5 VM running on AMD NEO II based host) AND with 100mS latency added to all outgoing packets on the server (via tc/qdisc). Also, FWIW, the graphics HW on this system is an nVidia ION based chipset. -brian ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-11-30 16:52 Message: Robert, I just committed r4820 which seems to fix this issue. Please test it out and report back. Thanks, -brian ---------------------------------------------------------------------- Comment By: Robert (ragoley) Date: 2011-11-29 08:40 Message: I was working strictly with the Tight encoder. The only time I used the other encoders was when I was unable to connect with the tight encoder or auto selected. Saw no issues when connecting with RAW or ZRLE. I have consistently seen this problem on 2 Macs and with 1 Windows 7 machine. I have not seen it from my Windows XP environment yet. Both Macs have Snow Leopard and the included JRE which is 1.6 based. The Windows XP JRE is 1.6.0_29 according to "java -version". Have not seen that message from my Linux environments either. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-11-29 07:49 Message: I confirmed this last night. Starting the viewer with Tight encoding selected and switching to ZRLE causes the crash consistently. This bug was probably introduced in r4819. I tried reverting the change to JavaInStream and that did not fix it, so it must be in the TightDecoder changes. I'll look at it again some more tonight. ---------------------------------------------------------------------- Comment By: Robert (ragoley) Date: 2011-11-29 07:02 Message: Small update to this issue. Getting the Rect too big error on 32 bit Mac OSX as well. My coworker has encountered the same problem on OSX 10.6 running on a 32 bit Mac Mini revision 1,1. Switching the encoder to anything other than tight allows him to connect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3444605&group_id=254363 ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
