Using the wxDC origin to implement scrolled drawing can require very large origin offsets, which can exceed Cairo coordinate limits (2^23), and therefore currently wxGTK3 limits as well. Managing the scroll offsets turns out to be pretty simple in this case, avoiding any coordinate limitations.
See #25365
https://github.com/wxWidgets/wxWidgets/pull/26614
(2 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
Thanks! This is good and useful, as it solves a real problem, but I still wonder if we could do this inside wxDC itself, i.e. handle the offset ourselves instead of relying on Cairo for this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
but I still wonder if we could do this inside
wxDCitself
It looks pretty unappealing to me. I think we would have to do the whole matrix transform ourselves for every point and size in every function in wxGCDC.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
but I still wonder if we could do this inside
wxDCitselfIt looks pretty unappealing to me. I think we would have to do the whole matrix transform ourselves for every point and size in every function in
wxGCDC.
Yes, true. It would, however, be simple to do it if the transformation is restricted to the origin shift (well, maybe axis scaling could be taken into account as well). This would still require modifying all the functions, but it's such an important use case (because this bug affects not just this control, but probably wxGrid, wxDVC, wxVListBox as well) that it might still be worth doing it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Well, regardless of whether it would be terrible or merely awful, I don't think a wxGCDC solution is going to happen before 3.3.3.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Sure, this should be merged to fix the problem. But I don't know if it's more or less awful to do the same thing in all the other affected classes (which still wouldn't fix it in the user code) or do it once in wxDC.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()