Pivot
  1. Pivot
  2. PIVOT-754

Pivot displays ugly gray box sometimes before it loads the applet

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0, 2.0.1, 2.0.2
    • Fix Version/s: 2.5
    • Component/s: wtk
    • Labels:
      None
    • Environment:
      Observed both on Linux and Windows Vista, Firefox 3.x and Firefox 4.0.1
      Java 6 update 25.

      Description

      When the applet starts, a progress bar is displayed. When the applet finishes downloading, the progress bar disappears, leaving a gray box until the pivot toolkit loads the application. Even for the simpliest application displaying an empty window, pivot requires about 0.3 s to start (on Core2Duo 2.2 GHz), so the gray box effect can be easily seen. The gray box effect does not happen always, but in about half of the cases.

      Below I submit patch we made to the BrowserApplicationContext.java file. Seems like setting the applet's background to white and delaying the add(displayHost) call as late as possible does the trick:

      [code]
      51a52
      > private boolean displayHostInstalled = false;
      151c152,154
      < add(displayHost);

      >
      > // Don't add it now, add it later, to avoid ugly gray box:
      > //add(displayHost);
      160c163,164
      < setBackground(null);

      > // Huh? WTF?
      > // setBackground(null);
      191a196
      > installDisplayHostIfNeeded();
      245a251,257
      > private void installDisplayHostIfNeeded() {
      > if (!displayHostInstalled)

      { > this.add(displayHost); > displayHostInstalled = true; > }

      > }
      >
      247a260
      > this.setBackground(Color.white);
      309a323
      > installDisplayHostIfNeeded();

      [/code]

      1. pivot-graybox.patch
        0.8 kB
        Piotr Kołaczkowski

        Issue Links

          Activity

          Hide
          Sandro Martini added a comment - - edited

          Reassigned, because Piotr is no more active in the project. Is someone interested ?

          Verify the proposed patch, to avoid side effects.

          Show
          Sandro Martini added a comment - - edited Reassigned, because Piotr is no more active in the project. Is someone interested ? Verify the proposed patch, to avoid side effects.
          Hide
          Sandro Martini added a comment -

          Hi, some news on this ?

          Piotr, excuse me, could you update the patch to the latest trunk to simplfy my work ?

          Thanks,
          Sandro

          Show
          Sandro Martini added a comment - Hi, some news on this ? Piotr, excuse me, could you update the patch to the latest trunk to simplfy my work ? Thanks, Sandro
          Hide
          Sandro Martini added a comment -

          Hi Piotr,
          thanks for the info, we'll try to see what/how to improve it, but for many users we have even to ensure that deploy without jnlp works good. And maybe say them "reccommended deploy of applets is this ...".

          >You should perhaps consider adding a background color as a parameter to the applet.
          Yes, will do it, good suggestion.

          What others say on this patch (probably need to be updated to latest trunk) ?

          Bye

          Show
          Sandro Martini added a comment - Hi Piotr, thanks for the info, we'll try to see what/how to improve it, but for many users we have even to ensure that deploy without jnlp works good. And maybe say them "reccommended deploy of applets is this ...". >You should perhaps consider adding a background color as a parameter to the applet. Yes, will do it, good suggestion. What others say on this patch (probably need to be updated to latest trunk) ? Bye
          Hide
          Piotr Kołaczkowski added a comment -

          >> The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box.
          > On this I don't know if we could do something, probably it's domain of the JVM+OS, but we can take a look to see what is possible

          I'm almost sure it is a deployment problem, not JVM+OS one. Our application using Apache Pivo, runs on the same JVM+OS and, thanks to custom BrowserApplicationContext, it doesn't exhibit the graybox problem at all. Even without the proposed changes, the graybox appeared only for a very short amount of time - the time after the JVM passed control to the applet after downloading the jars but before the DisplayHost managed to paint for the first time. However, in your demos, if the jars are not cached, the gray box appears for several seconds which makes it look like something is broken.

          From what I can see in the page source code, you deploy the applets using JavaScript, while we deploy them using JNLP with custom progress bar. Maybe this makes the difference.

          Show
          Piotr Kołaczkowski added a comment - >> The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box. > On this I don't know if we could do something, probably it's domain of the JVM+OS, but we can take a look to see what is possible I'm almost sure it is a deployment problem, not JVM+OS one. Our application using Apache Pivo, runs on the same JVM+OS and, thanks to custom BrowserApplicationContext, it doesn't exhibit the graybox problem at all. Even without the proposed changes, the graybox appeared only for a very short amount of time - the time after the JVM passed control to the applet after downloading the jars but before the DisplayHost managed to paint for the first time. However, in your demos, if the jars are not cached, the gray box appears for several seconds which makes it look like something is broken. From what I can see in the page source code, you deploy the applets using JavaScript, while we deploy them using JNLP with custom progress bar. Maybe this makes the difference.
          Hide
          Sandro Martini added a comment -

          This requires more tests, so move to 2.0.2

          Show
          Sandro Martini added a comment - This requires more tests, so move to 2.0.2
          Hide
          Sandro Martini added a comment -

          Hi all,
          > I don't think it is needed to distribute proguarded jars. I suggested only proguarding and packing the applications used as examples on the site, and reviewing if they are deployed correctly.
          That was my plan.
          But to avoid licensing problems etc (I can try to verify in the meantime with legal-discuss, just to close the discussion on it), maybe we could publish the pack200 version of our jars (signed and not signed) in the web site (and only there), so our demos and examples could have smaller downloads ... but wait, I see our client-side jars are approx. 4.2 MB (with our default build options, so they will contain debug info) and the same in pack200 version is less than 2.0 MB (stripping out debug info) so probably could be useful to put them in the same folder of web site and enable its usage in our pages, but I repeat only for web demos and tutorials ...

          On a profile for ProGuard maybe we could try to put a sample of it in our svn ...

          Both things are now under this ticket:
          https://issues.apache.org/jira/browse/PIVOT-755

          > The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box.
          On this I don't know if we could do something, probably it's domain of the JVM+OS, but we can take a look to see what is possible.

          Show
          Sandro Martini added a comment - Hi all, > I don't think it is needed to distribute proguarded jars. I suggested only proguarding and packing the applications used as examples on the site, and reviewing if they are deployed correctly. That was my plan. But to avoid licensing problems etc (I can try to verify in the meantime with legal-discuss, just to close the discussion on it), maybe we could publish the pack200 version of our jars (signed and not signed) in the web site (and only there), so our demos and examples could have smaller downloads ... but wait, I see our client-side jars are approx. 4.2 MB (with our default build options, so they will contain debug info) and the same in pack200 version is less than 2.0 MB (stripping out debug info) so probably could be useful to put them in the same folder of web site and enable its usage in our pages, but I repeat only for web demos and tutorials ... On a profile for ProGuard maybe we could try to put a sample of it in our svn ... Both things are now under this ticket: https://issues.apache.org/jira/browse/PIVOT-755 > The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box. On this I don't know if we could do something, probably it's domain of the JVM+OS, but we can take a look to see what is possible.
          Hide
          Piotr Kołaczkowski added a comment -

          I don't think it is needed to distribute proguarded jars. I suggested only proguarding and packing the applications used as examples on the site, and reviewing if they are deployed correctly. The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box. When jars have been cached, everything is fine, so you might not notice this.

          Show
          Piotr Kołaczkowski added a comment - I don't think it is needed to distribute proguarded jars. I suggested only proguarding and packing the applications used as examples on the site, and reviewing if they are deployed correctly. The first time I ran the examples, the progress bar disappeared too early, and the application was still downloading, while presenting me an ugly gray box. When jars have been cached, everything is fine, so you might not notice this.
          Hide
          Greg Brown added a comment -

          I don't know if we could do that. I know we can't do it as part of the build since that would require including the ProGuard JARs in SVN, which we're not allowed to do. I'd suggesting asking the question on legal-discuss if you are really interested in pursuing it.

          But OTOH, the Pivot JARs are already pretty small. We might be able to shrink them further, but I don't really see a huge advantage (especially since, as Piotr noted, it can be done after the fact by the application developer).

          Show
          Greg Brown added a comment - I don't know if we could do that. I know we can't do it as part of the build since that would require including the ProGuard JARs in SVN, which we're not allowed to do. I'd suggesting asking the question on legal-discuss if you are really interested in pursuing it. But OTOH, the Pivot JARs are already pretty small. We might be able to shrink them further, but I don't really see a huge advantage (especially since, as Piotr noted, it can be done after the fact by the application developer).
          Hide
          Sandro Martini added a comment -

          Right, but we could use it by hand to shrink pack200 version of Pivot jars for the site, ok ?

          And on the ticket to improve the (download) user experience, what do you think ?

          Show
          Sandro Martini added a comment - Right, but we could use it by hand to shrink pack200 version of Pivot jars for the site, ok ? And on the ticket to improve the (download) user experience, what do you think ?
          Hide
          Greg Brown added a comment -

          Correct - since ProGuard is GPL, we cannot use it to generate our JARs.

          Show
          Greg Brown added a comment - Correct - since ProGuard is GPL, we cannot use it to generate our JARs.
          Hide
          Sandro Martini added a comment - - edited

          Hi all,
          on the ProGuard usage on our jars, we can try it and then publish the ProGuard configuration used in svn, to reuse it.
          And of its usage, I'd not recommend to shrink method and field names (or stacktraces etc will be unreadable).
          To use from Ant, it's another story, I don't know it the license is compatible with apache ... look here: http://proguard.sourceforge.net/index.html#/license.html
          but probably the first way could be enough for us.

          The pack200 is for sure a good improvement, and we could do it as soon as possible, simply publishing the pack.gz (with or without the ProGuard shrinking, it's a detail) to our web site, improving the user (download) experience ... and if not already ok, a little change could be done in our applet tags to enable it.
          Maybe a ticket for this could help, I could create and take a look, ok ?

          Bye

          Show
          Sandro Martini added a comment - - edited Hi all, on the ProGuard usage on our jars, we can try it and then publish the ProGuard configuration used in svn, to reuse it. And of its usage, I'd not recommend to shrink method and field names (or stacktraces etc will be unreadable). To use from Ant, it's another story, I don't know it the license is compatible with apache ... look here: http://proguard.sourceforge.net/index.html#/license.html but probably the first way could be enough for us. The pack200 is for sure a good improvement, and we could do it as soon as possible, simply publishing the pack.gz (with or without the ProGuard shrinking, it's a detail) to our web site, improving the user (download) experience ... and if not already ok, a little change could be done in our applet tags to enable it. Maybe a ticket for this could help, I could create and take a look, ok ? Bye
          Hide
          Piotr Kołaczkowski added a comment - - edited

          No problem, but that is really not any magic. We use the standard Proguard recipe for proguarding libraries - there is an example on the Proguard page. We noticed, that although proguarding a library doesn't shrink it significantly (you may get only 30% improvement), there is a huge impact of doing a pack200 on the resulting proguarded jar. It looks like proguard optimisations helped pack200 work better. Anyway, you can even try pack200 alone - 3 fold size reduction is almost sure.

          "Have you tried setting the background of the Pivot Display instance?"
          Yes, and it didn't work either.

          Show
          Piotr Kołaczkowski added a comment - - edited No problem, but that is really not any magic. We use the standard Proguard recipe for proguarding libraries - there is an example on the Proguard page. We noticed, that although proguarding a library doesn't shrink it significantly (you may get only 30% improvement), there is a huge impact of doing a pack200 on the resulting proguarded jar. It looks like proguard optimisations helped pack200 work better. Anyway, you can even try pack200 alone - 3 fold size reduction is almost sure. "Have you tried setting the background of the Pivot Display instance?" Yes, and it didn't work either.
          Hide
          Greg Brown added a comment -

          Have you tried setting the background of the Pivot Display instance?

          Show
          Greg Brown added a comment - Have you tried setting the background of the Pivot Display instance?
          Hide
          Chris Bartlett added a comment -

          > Also you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB.

          Piotr - Have you successfully used ProGuard with any Pivot apps?
          If so, would you be able to share your experiences and any useful tips?
          I'm sure it would be useful for others on the mailing lists.

          There was a thread about ProGuard a few months ago, but it didn't get many replies.
          http://apache-pivot-users.399431.n3.nabble.com/Using-ProGuard-tp2319417p2319417.html

          Show
          Chris Bartlett added a comment - > Also you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB. Piotr - Have you successfully used ProGuard with any Pivot apps? If so, would you be able to share your experiences and any useful tips? I'm sure it would be useful for others on the mailing lists. There was a thread about ProGuard a few months ago, but it didn't get many replies. http://apache-pivot-users.399431.n3.nabble.com/Using-ProGuard-tp2319417p2319417.html
          Hide
          Piotr Kołaczkowski added a comment -

          [quote]
          Not sure - you'll have to look on the Oracle site for that (they aren't specific to Pivot)[/quote]

          So, no then it wouldn't work. The first thing we tried was calling setBackground on the applet container instance, even before the applet gets init(). It is possible from the DownloadServiceListener class which gets the reference to the loaded applet before the applet even knows it exist.

          The problem is not only "not setting the background", but that the background gets immediately covered by the displayHost at the startup, and the displayHost is uncapable of displaying anything useful until it fully initializes.

          [quote]
          What is 13MB? The biggest JAR I see is 1.9MB: [/quote]

          our code + Scala + Pivot = 13 MB without Proguard and pack200.
          our code + Scala + Pivot = 1 MB with Proguard and pack200 applied separately to all jars (with all public/protected code retained!)
          our code + only things really used from Scala and Pivot would be even less.

          Conclusion: you can get about 10x compression of your jars with Proguard + pack200, without dropping any functionality.

          Show
          Piotr Kołaczkowski added a comment - [quote] Not sure - you'll have to look on the Oracle site for that (they aren't specific to Pivot) [/quote] So, no then it wouldn't work. The first thing we tried was calling setBackground on the applet container instance, even before the applet gets init(). It is possible from the DownloadServiceListener class which gets the reference to the loaded applet before the applet even knows it exist. The problem is not only "not setting the background", but that the background gets immediately covered by the displayHost at the startup, and the displayHost is uncapable of displaying anything useful until it fully initializes. [quote] What is 13MB? The biggest JAR I see is 1.9MB: [/quote] our code + Scala + Pivot = 13 MB without Proguard and pack200. our code + Scala + Pivot = 1 MB with Proguard and pack200 applied separately to all jars (with all public/protected code retained!) our code + only things really used from Scala and Pivot would be even less. Conclusion: you can get about 10x compression of your jars with Proguard + pack200, without dropping any functionality.
          Hide
          Greg Brown added a comment -

          > We haven't tried that. Where is the list of possible params documented?

          Not sure - you'll have to look on the Oracle site for that (they aren't specific to Pivot).

          > you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB.

          What is 13MB? The biggest JAR I see is 1.9MB:

          http://pivot.apache.org/lib/

          Show
          Greg Brown added a comment - > We haven't tried that. Where is the list of possible params documented? Not sure - you'll have to look on the Oracle site for that (they aren't specific to Pivot). > you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB. What is 13MB? The biggest JAR I see is 1.9MB: http://pivot.apache.org/lib/
          Hide
          Piotr Kołaczkowski added a comment -

          1) To avoid adding displayHost twice - when I wrote it, I wasn't sure in how many places it is needed, if I remove it from init. Anyway, feel free to remove it and replace by just add(displayHost) if you think it is ok.
          2) True, that is why it needs some tweaking. It is not a final solution, it is just an example that works for us. You should perhaps consider adding a background color as a parameter to the applet.
          3) We haven't tried that. Where is the list of possible params documented? However, I don't see a purpose for that - why display an image to the user, for about 0.3 - 0.5 seconds? Before the applet download, there is a splash screen with custom download progress bar and a logo - it is enough. And the clear white applet loads and displays insanely fast, so there is no risk of that gray thing ever showing.

          BTW: There is something messed up with deployment of most of the sample applets on the Pivot page. The Java progress bar disappears and displays a gray box not for half a second, but for much much longer, until all the jars finish downloading. Also you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB.

          Show
          Piotr Kołaczkowski added a comment - 1) To avoid adding displayHost twice - when I wrote it, I wasn't sure in how many places it is needed, if I remove it from init. Anyway, feel free to remove it and replace by just add(displayHost) if you think it is ok. 2) True, that is why it needs some tweaking. It is not a final solution, it is just an example that works for us. You should perhaps consider adding a background color as a parameter to the applet. 3) We haven't tried that. Where is the list of possible params documented? However, I don't see a purpose for that - why display an image to the user, for about 0.3 - 0.5 seconds? Before the applet download, there is a splash screen with custom download progress bar and a logo - it is enough. And the clear white applet loads and displays insanely fast, so there is no risk of that gray thing ever showing. BTW: There is something messed up with deployment of most of the sample applets on the Pivot page. The Java progress bar disappears and displays a gray box not for half a second, but for much much longer, until all the jars finish downloading. Also you should consider using Proguard and pack200 - the download size of the samples is pretty huge. We could get a complete application with Scala + Pivot 2.0 + our code down to about 1 MB instead of 13 MB.
          Hide
          Greg Brown added a comment -

          Couple of questions/comments:

          1) Why is installDisplayHostIfNeeded() necessary?

          2) This patch seems like it could create a similar problem if the page background is not white (users would briefly see a white box against the page background color).

          3) Have you tried specifying an image param to your applet? e.g.

          <PARAM NAME="image" VALUE="animated_gif.gif">

          Show
          Greg Brown added a comment - Couple of questions/comments: 1) Why is installDisplayHostIfNeeded() necessary? 2) This patch seems like it could create a similar problem if the page background is not white (users would briefly see a white box against the page background color). 3) Have you tried specifying an image param to your applet? e.g. <PARAM NAME="image" VALUE="animated_gif.gif">
          Hide
          Piotr Kołaczkowski added a comment -

          A patch for the Pivot 2.0 BrowserApplicationContext.java file.

          Show
          Piotr Kołaczkowski added a comment - A patch for the Pivot 2.0 BrowserApplicationContext.java file.

            People

            • Assignee:
              Unassigned
              Reporter:
              Piotr Kołaczkowski
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development