06-02-2018, 10:46 AM (This post was last modified: 06-02-2018, 10:49 AM by mcrossy.)
Hi Mike,
I've noticed the highlighter tool draws it's lines by covering up what is in the background, instead of being transparent like a true highlighter.
I know we can set it's transparency level so it becomes a bit transparent, but doing so we loose half of the colour of the line, and the background becomes a bit less contrasted.
In drawing apps as Photoshop the highlighter effect is made by setting overlapping mode to "multiply", so that every level can maintain full colour and contrast even if they are set to 100% opacity. Do you think it would be possible also in MSP?
Marco
Samsung Galaxy S8 Ultra 14.6" - Nord Stage 2 HA88
I agree with mcrossy. That's an important disadvantage of MSPs highlighter tool.
Sometimes I use the highlighter of my PDFReader that has "multiply mode" and highlight directly in the PDF losing all of MSPs flexibility.
It's definitely something I want to do, and I've tried to explore how to do it, but I haven't found anything that has worked so far. I've tried changing the way the painting of the highlighter works on Android by utilizing different PorderDuff Xfermode values, but no matter what I try, the drawing either goes on top of the image or behind it. So that approach doesn't seem to be sufficient unless I'm doing something wrong. That leads me to believe I have to modify the pixels behind on the content on the page myself instead of relying on a blending/multiplying technique. Having to modify the pixel values of the bitmap representing the page is not the simplest thing when dealing with a freeform drawing, which is why I haven't done something about this yet.
(06-03-2018, 04:36 AM)Zuberman Wrote: It's definitely something I want to do, and I've tried to explore how to do it, but I haven't found anything that has worked so far. I've tried changing the way the painting of the highlighter works on Android by utilizing different PorderDuff Xfermode values, but no matter what I try, the drawing either goes on top of the image or behind it. So that approach doesn't seem to be sufficient unless I'm doing something wrong. That leads me to believe I have to modify the pixels behind on the content on the page myself instead of relying on a blending/multiplying technique. Having to modify the pixel values of the bitmap representing the page is not the simplest thing when dealing with a freeform drawing, which is why I haven't done something about this yet.
Mike
Hi Mike,
my idea could be making some kind of "mathematical operations" between graphic layers. In this way it could be possible to add or multiply, or even subtract, two or more layers so that their values combine themselves.
That's exactly what I tried to use. Here's something interesting I just found though - it works perfectly when using the rectangle draw mode for the highlighter. The highlight correctly goes behind the text (as the pixels are multipled and merged). The bug appears to be with using a Path to draw the highlight in combination with the porterduff xfermode. What I'm seeing is a black box around the highlight with the hightlight behind the black text. I'm trying to look for information, but I'm really hoping this isn't a limitation in Google's code. If I can figure out how to get past the issue with the black box, then I'll have a working solution (for Android at least, I don't think Windows 10 has an equivalent).
Well I found a solution. It's not the most performant, but I think in this case, having the highlighter function like people would expect is more important.
Those aren't really applicable for this. I'm using a Canvas to draw a Path object on top of an existing ImageView. So in order to blend the pixels, I have to use a PorterDuffXferMode with the Paint object used to draw the Path. There is an issue when doing that directly on top of the ImageView though, so instead, I have to render the freeform annotation to a background bitmap, then blend the two bitmaps.
06-04-2018, 03:38 AM (This post was last modified: 06-04-2018, 03:42 AM by Zubersoft.)
The ImageView contains an opaque bitmap (the rendered score) using RGB 565 which dramatically reduces memory usage versus using ARGB8888. Most scores don't actually have transparent backgrounds though - they have solid white. So rendering the path under the ImageView would result in no blending occurring at all. It's a good thought though, but I think the real issue here is the Android framework. If you use the PorterDuffXferMode with MULTIPLY, and you render to a hardware accelerated canvas using a path, it's going to generate that black background. This seems to be a known issue, and the answer is always to use a non-hardware accelerated canvas backed by a bitmap to draw the stuff you want to blend.
Due to the way the Windows 10 rendering framework works (where every thing you want to render has to be an individual framework element unless you use directX to render the 2D stuff yourself), I do not have a solution for how to blend highlights with the rendered score to put the highlight behind. Either I'd have to implement some very crazy code to modify the rendered bitmap itself and blend the pixels (essentially duplicating the rendering code used by frameworks like skia/cairo), or I'd have to switch my entire rendering engine to DirectX, which would probably be a nightmare and would take endless months to get everything working properly again.
(06-04-2018, 03:38 AM)Zuberman Wrote: ....
If you use the PorterDuffXferMode with MULTIPLY, and you render to a hardware accelerated canvas using a path, it's going to generate that black background.
And what happens if you use ADD or other operators?
Marco
Samsung Galaxy S8 Ultra 14.6" - Nord Stage 2 HA88
