Bug Tracker item #3444605, was opened at 2011-11-28 15:42
Message generated for change (Comment added) made by bphinz
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: Closed
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: Brian Hinz (bphinz)
Date: 2011-12-23 12:10

Message:
Closing as "FIXED".  I will open another ticket as a "Feature Request" so
that we can continue discussing the performance issues.

----------------------------------------------------------------------

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

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to