Author |
Message |
11/03/2014 14:46:01
|
struemper
Active
Joined: 25/03/2013 17:05:57
Messages: 11
Offline
|
I already recently asked how to dynamically scale the CC Client using code and/or UI element.
That generally worked pretty well, but now that we're planning to implement it we've found a couple of minor annoyances and problems which we'd like to fix first:
1. When changing the scaling, the screen flashes two times. I can only guess about that, but as far as I know, CC first rescales the UI and then the fonts. Or the other way around.
Does it change the sizefactor and fontfactor variables one by one?
Can we reduce the screenflashing to _1_ flash per scalechange?
Or does it need to complete the UI rearrangement (after changing size- or fontfactor first) to guess and approximate the new UI sizes?
2. We want to allow a user to set a custom scaling (from 50%-200%) and start the client in that scaling.
However, since the function to change the scaling is embedded in a CC element ( t:clientconfig, attribute "scale"), we first have to load the UI with a basic scaling, requesting the starting page from the server and inflating the whole UI, retrieve the user-specific scale from the DB and the client rescales.
As described in 1., two screen-flashes happen.
Does the client load and request the "starting page" two additional times (once per screenflash) compared to starting the client in a default scaling?
Or does it simply rescale the UI locally, without re-requesting the starting page from the server?
3. IF the starting page is requested two additional times:
To reduce load on the server when users are starting up their CC-workplace and since our start-page is customizable and rather complex...
Can we somehow let the client dynamically start up with a user-specific scaling OR avoid inflating the whole UI before we've set the scale?
IF that isn't possible:
Can we somehow get a trigger or a hook which would tell the client when the inflating is done?
We'd just show a simple "Welcome" splash screen, wait until the CC started up with the standard scaling, load and apply the user-specific scaling, and when the trigger/hook says, that it's done with that, we'd load the actual UI, avoiding two additional, very ressource intensive roundtrips with a lot of searching and building up fixgrids.
|
|
|
11/03/2014 16:00:46
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5555
Offline
|
Hi,
@1) ...there is definitely some heavy flickering - due to the fact that the whole screen needs to be rearranged/resized/redrawn. If one or two times, hmm - but we cannot avoid the effect that the user sees that something major is going on.
@2) ...the client reloads the complete page from the server side, so it's not updating its current controls but builds up the controls from the scratch
@3) ...you only can do this controlled by your application: start with a thin intro screen and then switch over to a complex workplace.
You can do this using a timer.
In general: on JavaFX Side resizing is very simple and does not require any reload - because scaling is a built in feature on any component level. But on Swing side, we have to do quite a lot of "stupid things" to make it possible: all the resizing is done by ourselves, e.g. we have to update the font settings within the look and feel etc. etc.
Hope, this helps...
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
|
|
|