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

Text draw speed regression #1500

Closed
edvv opened this issue Dec 2, 2016 · 7 comments
Closed

Text draw speed regression #1500

edvv opened this issue Dec 2, 2016 · 7 comments
Assignees
Milestone

Comments

@edvv
Copy link

edvv commented Dec 2, 2016

Dear WinObjC Engineers,

From release 41 to 42 there is a regression in text drawing speed. Release 41 is about 10 to 100 times faster than 42. It is a very significant effect. Release 41 text draw speed was similar to an iPad, while Release 42 is an order of magnitude or two slower.

See also #1374

Sincerely,

Ed

@rajsesh
Copy link
Contributor

rajsesh commented Dec 2, 2016

@edvv could you please explain what text draw API you are seeing regression in? What formatting you are using and the contents?

@edvv
Copy link
Author

edvv commented Dec 2, 2016

@rajsesh-msft The API is that of the project at this URL:

#1335

Where [aString drawAtPoint:aPoint withAttributes:stringAttributes]; is called tens to hundreds of times for tables formatted as shown at this URL:

http://www.vvidget.org/manuals/GraphIDE/Controls/Tables/index.html

and while scrolling. It is noticeable by a user while scrolling, but is not particular to this situation.

Sincerely,

Ed

@edvv
Copy link
Author

edvv commented Dec 6, 2016

This problem persists with release 43.

@antoine-haas
Copy link
Contributor

antoine-haas commented Dec 7, 2016

Thanks for trying it out with the new release @edvv. This is currently being investigated by #1374.

@rajsesh
Copy link
Contributor

rajsesh commented Dec 15, 2016

@eddv, thanks for reporting this. We had seen the regression internally as well. We will use #1374 for tracking perf issues. We will likely have to address these over a couple of iterations. For example, #1490 is also hit quite a bit in this code path.

@rajsesh rajsesh closed this as completed Dec 15, 2016
@rajsesh rajsesh reopened this Dec 16, 2016
@rajsesh
Copy link
Contributor

rajsesh commented Dec 16, 2016

#1374 won't fix all issues afterall, so we will keep this active for now.

@rajsesh rajsesh added this to the 1701 milestone Jan 3, 2017
@rajsesh
Copy link
Contributor

rajsesh commented Jan 4, 2017

Issue #1620 will improve the performance. We will re-evaluate perf after that work and iterate.

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

4 participants