Hello,
I like the the new feature "Annotation highlights are now drawn behind the page content", they are much better to read.
But I see a strange behaviour when turning in half pages: the highlights of the hidden half page are visible and vice versa, especially on pages which were trimmed or used twice in a title (eg. for D.S. parts).
See two screenshots attached, just before and after half-page turning.
It is reproducable on my android device (a Hannspad 14", still on Android 4.4.4) but also on my Samsung mobile with Android 8.1. When I disable the new feature everything is fine, but I would like to keep the new mode.
Anybody else has the same issue? Any idea how to fix it?
Thanks,
Michael
Michael,
That sounds to me like a bug with the half page display. In order to get the highlight annotations to show up behind the page content, I actually have to render them to a backbuffer and then perform blending between that backbuffer and the image of the page in order to create the effect. The problem with the half page display is that I'm rendering the entire page to that backbuffer, and not accounting for the half page clipping. I'll have to see what I can do about that. Thanks for letting me know about the issue.
Mike
Mike,
Thanks for your quick reply, as always.
This is one oft the finest pieces of software available and my most important one. Additionally your service and the continious effort to improve the Software is awesome and benchmark.
Thanks for making my musician's life easier!
Michael
Just wanted to say that the new update (v2.3.1) does not include a fix for this yet, as I have not had time yet to identify exactly what changes will be needed. Due to the large number of issues that are being seen with the new feature, I'm going to have to do a lot more work on it.
Mike
(07-24-2018, 03:01 AM)Zuberman Wrote: [ -> ]Just wanted to say that the new update (v2.3.1) does not include a fix for this yet, as I have not had time yet to identify exactly what changes will be needed. Due to the large number of issues that are being seen with the new feature, I'm going to have to do a lot more work on it.
Mike
Never mind Mike, you've made a lot of great work and we all users are very grateful for this.
Hope you'll find a good solution for that feature that can work with all devides, since I'm waiting for it, as you well know... ;-)
Again... thanks alot!
Hello again!
It's great to see that the highlight feature now works almost perfectly. But there are a couple of things that I'd like to report (my device is Samsung Note Pro 12.2). These assume that the new feature is enabled:
1: the page containing highlighted annotations loads very slowly; this doesn't occur when new feature is OFF
2: if I draw highlights near the right border of the page, a couple of cms are hidden; turning the new feature OFF they appear back correctly
3: if the opacity of the highlighted lines is set to 255, in edit mode it shows correctly the line, but when I save and exit, it shows a black rectangle that covers the selection of the drawings. Setting opacity other than 255 doesn't show this problem.
Also I'd like to share a perso al opinion: you inserted the button to enable the "highlight behind" feature inside the edit mode: I think this should be perfect if it could work for that song being edited; I think that a general setting that affects to all the pages should be in the general settings menu of the app instead.
Hello Marco,
Thanks for the feedback.
1) There isn't much I can do about that most likely. The new method of drawing is much slower than the old method, but due to the complexity of blending the bitmaps (and having to use a backbuffer to do it), I doubt it can be made much faster.
2) I'll see if I can reproduce that.
3) I've located the bug and fixed it.
All of the settings under the annotations editor are global settings - they are not per song. So I don't think there is anything incorrect about having that setting there. It also keeps all of the annotation specific settings together. I'm always open to changing it though if most people think it's better if it's under the main display settings.
Thanks,
Mike
I can't seem to reproduce the problem you are seeing with #2. Are you using line annotations or freeform annotations? Perhaps the fix for #3 will fix this as well if it's with line annotations and opacity 255. If not, can you take a screenshot?
Thanks,
Mike
(08-06-2018, 08:59 AM)Zuberman Wrote: [ -> ]I can't seem to reproduce the problem you are seeing with #2. Are you using line annotations or freeform annotations? Perhaps the fix for #3 will fix this as well if it's with line annotations and opacity 255. If not, can you take a screenshot?
Thanks,
Mike
Hello Mike,
The problem #2 occurs with all kinds of lines (freeforms or other objects). Here are 2 screenshots where to compare what happens with feature ON and OFF (look at the bottom right of the images).
The same effect occurs with my 2 tablets (Samsung Galaxy Note Pro 12.2 and Samsung Galaxy Tab 3 10.1).
(08-06-2018, 07:50 AM)Zuberman Wrote: [ -> ]1) There isn't much I can do about that most likely. The new method of drawing is much slower than the old method, but due to the complexity of blending the bitmaps (and having to use a backbuffer to do it), I doubt it can be made much faster.
Mike, I've got an idea to make the displaying a bit faster, specially for older tablets, don't know if it's practicable.
Let suppose you are in Performance mode, while you are reading a page: in the meanwhile the processor is supposed to be inactive. In this period MSP could render the "next page in list" in background, so, when the user recalls the next page, it should be ready to display without having to render it from scratch. What do you think about?
That's actually already how it works. Bitmaps are rendered for up to 5 pages forward and 3 pages back (those bitmaps don't include the annotations). In the rendering engine, a certain number of pages are actually rendered on and off the screen depending upon which display mode is currently active. For the single page display, the current page, previous page and next page are all rendered and ready to go. So in theory, unless you are turning pages quickly and things are rendering quite slowly, each page should already be drawn when you turn the page.
Mike
(08-07-2018, 08:38 AM)Zuberman Wrote: [ -> ]That's actually already how it works. Bitmaps are rendered for up to 5 pages forward and 3 pages back (those bitmaps don't include the annotations).
That sounds perfect... But did you tried to render the pages including also the annotations? I think this should reduce loading times when recalling those pages (eventually this option could be enabled or disabled by a switch in the setup menu).