• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

setVisible takes too long to return

 
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello all,
I just wrote a little JComboBox test and I ran into a problem that I can't explain (and I couldn't find information on it in the net after a quick search). Maybe I just missed something obvious.
Here is the little program. It just adds a JComboBox to a JFrame. When I run this program the frame pops up, but it takes a while until the combo actually gets added.
the print statements show that the method setVisible takes unusually long to return. I say, unusually as I never noticed this problem before.
Could someone tell me what happens here?
 
Bartender
Posts: 4121
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I changed your code to calculate how many milliseconds it took to do each step... I don't see any problems..



I get output that looks like this...

 
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wuhh...
I am running this on linux, jdk 1.4.1-beta. I compiled it with a call to javac without setting any options.
The output is:
created frame - 825
created data store - 2
populated data store - 1
created combo - 308
combo added - 0
pack - 264
set visible - 5120
The really weird thing is, I am developing complex guis on this system and I never noticed this behaviour.
compiling with g:none (debugging of) results in:
created frame - 945
created data store - 1
populated data store - 1
created combo - 321
combo added - 1
pack - 273
set visible - 5133
that's even worse.
What's happening? is this a parallel universe?
Maybe I should sacrifice some profiler evaluation copy to see what's going on?!
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
just compiled and ran the program on different jdks: 1.4.0 and 1.4.1 doesn't defer much, but the result of jdk 1.3 (IBM jit-enabled) is:
created frame - 1009
created data store - 2
populated data store - 0
created combo - 778
combo added - 1
pack - 52
set visible - 323
jdk 1.3.1_04:
( haven't seen this error output (Font...) for a long time ;-) )
Font specified in font.properties not found [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific]
created frame - 2219
created data store - 1
populated data store - 1
created combo - 470
combo added - 1
pack - 145
set visible - 5021
just to throw some more benchmarks at you: the combobox is not the problem. adding a JTextField instead of a JComboBox doesn't make it faster:
created frame - 903
created text field - 176
text field added - 1
pack - 230
set visible - 5029
any ideas, comments, experiences? I'm definitely interested. is this really a linux problem?
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for not mentioning this in my earlier post...

The system I am running it on is a Pentium 4 1.8Ghz with Windows2K with JDK 1.3.1_01 (my machine at work... )

I'll try this out on my (much slower) machines at home and see what the numbers work out to...

I'm betting that most of the "native-peer" stuff gets set up in the setVisible() call, so that may behave different ways on different systems depending on the native resources being called... so there may be a speed difference between Windows and Linux implementations of the "native-peer" JDK code...

Anyone else out there have any numbers from running this?
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I paid more attention on how long my bigger apps take to come up. for example do I have a splash screen composed of a jframe and an image where the jframe pops up first and only after some moments the image is displayed.
so, obiously it's the jdk for linux. Although I have only (compared to you machine) 500Hz CPU, I don't (want to) think it's a CPU problem. 500Hz should be more than enough to process this little window!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!