Quote:
Originally Posted by dimasic
NuPogodi, you should say: "Sperva dobeysya!"  |
I'm just trying to explain you that most implemented features were discussed zillion times before they were finally implemented. Instead of forcing someone (i.e. the developer) to follow your personal requests that do not fit his reader concept, you should just copy the sources from github & change everything you want to.
That's the way it is.
@Kai771: as we started to discuss the overlap, i've just recalled my old intention I've totally forgotten: iirc, the points inside overlapped areas are processed twice -- first, when the reader engines (mupdf, crengine, etc) parse the page and fill the framebuffer by the point colors (see c-functions usually called drawCurrentPage) and then, if the overlap is on, again -- dimRect reads the colors of points inside the overlapped area & halves them. It could be treated as not a big deal, unless this procedure is repeated for each damned book page. I was intended to write new cre-function drawOverlappedPage [including the overlapping area as input parameter -- actually, just y1 & y2 that mark overlapped area] and thus to avoid double-processing.
PS. Not a request, just an info that could also help you to improve the reader performance