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

Using a fixed point FontUnit dimension for internal calculations. #22

Closed
cbreeden opened this issue Jan 10, 2017 · 0 comments
Closed

Using a fixed point FontUnit dimension for internal calculations. #22

cbreeden opened this issue Jan 10, 2017 · 0 comments

Comments

@cbreeden
Copy link
Collaborator

cbreeden commented Jan 10, 2017

On IRC we discussed the possibility of using a scale of internal font units (in xits it's 1/1000 em) for internal dimension in ReX. We concluded that it would probably be best if we use a 24.8 fixedpoint representation of the internal font unit. A cursory glance of the code showed that *2, /2, and +/- is by far the most common operation. However, *0.68 is used for scripts scaling, and it is unclear what the distribution of *0.68 use is to make a fully informed decision.

Pertinent numbers from the intel optimization manual:

Latency Throughput
ADD 1 0.5
MUL 7,8 6,7
SHL 1 1
FADD 5 4,1
FMUL 5 1

Considering the number of *2, /2 uses, it seems unlikely that f64 will afford the same bitshift optimizations that a u32 would. FDIV is not listed, but expensive.

sebk also pointed out that it could be possible to put a scaling call in both the layout and renderer, but depending on a feature flag, one would be a no op and the other wouldn't.

Using a scaled font unit would also rid of all the Pixels -> FontUnit conversions in the Layout (there seem to be quite a few).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant