Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve scaling quality for files with many lines #24

Open
nmatt opened this issue Jan 7, 2016 · 10 comments
Open

Improve scaling quality for files with many lines #24

nmatt opened this issue Jan 7, 2016 · 10 comments

Comments

@nmatt
Copy link

nmatt commented Jan 7, 2016

Currently (v1.3), text in different text lines appear to have a different height -- probably an artifact of the scaling algorithm used. It would be nice if the font size could be configured such that each text lines takes up an equal integral number of pixels in height (like for example 2 pixels or 3 pixels). Or else use a "smoother" scaling algorithm (e.g. bicubic).

@markiewb markiewb added this to the 1.3.1 milestone Jan 7, 2016
@markiewb markiewb changed the title Font size & scaling Use bicubic scaling for better quality Jan 7, 2016
@markiewb
Copy link
Collaborator

markiewb commented Jan 7, 2016

fixed in 1.3.1

@markiewb markiewb closed this as completed Jan 7, 2016
@markiewb
Copy link
Collaborator

markiewb commented Jan 7, 2016

@nmatt
Copy link
Author

nmatt commented Jan 8, 2016

It's improved, but there is still some strange moiréing going on. To illustrate, here is an example with 300 identical lines filled with "M":
moire
It looks a bit like the scaling is skipping certain rendered text pixel lines, so sometimes it only picks up the middle of the text line (=black) and sometimes only the space between text lines (=white).
Here is the same content scaled with Gimp to the same height (using "Cubic" interpolation):
gimp

@markiewb
Copy link
Collaborator

Strange. I will have a look. Perhaps I should disable anti-aliasing before scaling

@markiewb markiewb reopened this Jan 10, 2016
@markiewb
Copy link
Collaborator

Yes it looks strange. I can reproduce it. There is some logic regarding height.

If you like, you can debug it and fix it.
https://github.com/markiewb/nb-codeoutline/blob/master/src/main/java/bluej/editor/moe/NaviView.java

@p2rkw
Copy link

p2rkw commented Jan 11, 2016

@nmatt
Copy link
Author

nmatt commented Jan 12, 2016

Ok, the way it is currently implemented, i.e. rendering the text at a very small size into a buffer with the same height as the target area, probably can't ever look right. This is because the text rendering logic will render the text line by line into the buffer, where each line has only a fractional pixel height. This can't possibly produce high-quality results.

What needs to be done is to render the text into a much larger buffer, so that each text line is rendered with multiple pixels in height (preferably an integral (non-fractional) number of pixels to avoid aliasing differences between lines), and then scale this buffer down into the target graphics context. For very large files (10.000's of lines or more), this probably should be done in chunks to avoid out-of-memory due to buffer size.

@markiewb
Copy link
Collaborator

Perhaps that is the reason, why Sublime only shows font-size=1 lines?

@markiewb
Copy link
Collaborator

@markiewb
Copy link
Collaborator

I won't invest time to fix this issue. I am not using this plugin that often. Thank you for your understanding.

If you like to get it fixed, please provide a pullrequest! I would be happy to integrate it!

The relevant source file is
https://github.com/markiewb/nb-codeoutline/blob/master/src/main/java/bluej/editor/moe/NaviView.java

@markiewb markiewb changed the title Use bicubic scaling for better quality Improve scaling quality for files with many lines Jan 23, 2016
@markiewb markiewb removed this from the 1.3.1 milestone Jan 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants