Author |
Message |
Tillie
Joined: 2012-02-09 21:01:50 Posts: 284
|
Hello henri, one more thing. I made some JIRAs at LL and stuff, but apparently they ignore them. On the longin screen is this area with links to recommended sims etc. The links work until you have your SL window bigger than 'default', like when you see black bars left and right from the center area. Then the links are not working anymore... or rephrased: they are still working but not where you see the text you should click. Clickable area and visible link have quite some offset then. Is there a way to make this working on all screen sizes? If I want to click a link I first have to resize the window until there are no black borders anymore. And I guess for fullscreen sessions this is always broken.
|
2015-06-05 09:55:17 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5550
|
I'm afraid I don't understand what your issue is: what black bars, what links, what (exact) window size ?... Please give precise repro steps.
Please also note that anything that is rendered within an HTML page (like the login page) is beyond the control of the viewer itself. It might be an HTML/Javascript issue, or a bug in QtWebkit (the built-in browser linked to the viewer), but neither can be solved from my side.
|
2015-06-05 15:06:04 |
|
|
Tillie
Joined: 2012-02-09 21:01:50 Posts: 284
|
Yah, complicated. On the start screen, before logging in, you see links to the SL destinations and stuff. Usuall all those work. Now if you make the window wider so that the colored area with the link is not fulling the whole window anymore, the clicktargets to the links stay somewhere on the left. The wider you make the window, the further of the clicktargets are. As if the client doesnt recognize the screen size after a certain width. This is how it should work: And this is how it works when the screen is really wide: You see that the distance between the two arrows is exactly the width of the black filling bar on the left. So apparently there is an offset missing, that needs to be added somewhere.
|
2015-06-06 10:00:10 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5550
|
This looks like a bug dealing with window resizing events not being properly taken into account and passed to the UI elements and embedded plugins (here, the browser is not resized and since it's the viewer that sends the mouse position clicks to it, the coordinates don't match any more between the main window of the viewer and the browser frame); the "black bars" which confused me in your first message should not even exist at all !... This seems to happen when resizing by clicking on and dragging a corner of the viewer window (and it's even worst under Linux for which the UI elements at the bottom of the screen don't get moved/rearranged at all)... However, if you resize the window by dragging one of its sides (right, left or bottom border), things seem to work properly: can you confirm that on your system ? I can reproduce the same bug with LL's viewer (and all derived TPVs are therefore probably affected as well), but not with old Cool VL Viewer versions (v1.26.6 or older), neither with Singularity... I'll have a look and try to find the offending backport (this may take some time since it means finding which backport of LL's code, among the gazillion releases I made, broke the resizing...). In any case, it tells something about how often people resize the viewer window (I myself never do it)...
|
2015-06-06 15:50:12 |
|
|
Tillie
Joined: 2012-02-09 21:01:50 Posts: 284
|
I resize it a lot, to copy in or out script stuff or check snapshot folders etc. I dislike alt-tabbing through windows. And when the client starts up, I usually have it maxed to screen, which is REALLY big (UHDm, almost 4K resolution). And then it has the black bars and the wrong clickfields... Oh, and you asked... no matter HOW I resize the window, as soon as the window gets wider than something around 2048 pixels, it gets those black borders left and right. 2048 is an interesting number, but I think it's some pixels less.
|
2015-06-06 17:52:58 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5550
|
Now, that is a relevant and interesting info... In the mean time, I found when the resizing broke for Linux builds (in v1.26.8.66). It was because of the library refresh that saw SDL v1.2.15 replacing v1.2.14, and the former got a known resizing bug that LL forgot to patch in their pre-built library... So, in fact, that Linux bug is not what you are seeing under Windows, and indeed, the problem you might be having is probably related to your huge screen resolution... This lets me clueless about what might be causing it in either the viewer code or the QtWebkit library... And since I don't have a 4K screen to test and debug the viewer onto...
|
2015-06-06 19:02:17 |
|
|
Tillie
Joined: 2012-02-09 21:01:50 Posts: 284
|
Okies, at least you found that other bug. Btw. happens on a 2560x1440 display, too already.
|
2015-06-07 09:21:09 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5550
|
Well, yes, the limit beyond which it happens is probably an exact power of 2, and 2048 looks like a good candidate... "Limited" (it's more than enough for my taste/needs) to 1680 pixels wide, here, so I can't tell/test/debug.
|
2015-06-07 16:42:39 |
|
|
Tillie
Joined: 2012-02-09 21:01:50 Posts: 284
|
If you can compile some binary that just outputs all the data you need, I could try that. But maybe I can live with the problem too. It's more an annoyance, doesn't prevent me from doing something.
|
2015-06-09 15:48:32 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5550
|
I'm afraid it's more complicated than just spicing the code with log messages, and running the viewer under a debugger would be needed. Not something I can "remote-control" through another person.
|
2015-06-09 21:08:21 |
|
|