-
-
Notifications
You must be signed in to change notification settings - Fork 118
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
Refactor drawing subsystem #723
Conversation
Both ellipses and rectangles are drawn from a single object named "Area". Drawing logic depends on the source of an object: if it's from "rectangles" container, then draw a rectangle, otherwise draw an ellipse. This commit creates new separate "Ellips" type, which allows to: - hide a dedicated ellipsis rectangle drawing logic in a method associated only with "Ellips" objects - distinguish ellipses and rectangles by their types, not by the place they come from The name ("Ellips") has no "e" at the end because "Ellipse" conflicts with a painting with the same name, which is declared in the same namespace. I didn't want to go into any additional trouble and chose to go with this type of a "workaround".
Some classes have members of container types, storing "Ellips" objects, i.e. ellipses. Just assigning a proper name.
After extracting ellipse from "Area" to a separate class, "Area" means only a rectangle.
This is a helper function required for some future changes.
DrawingPrimitive is a common interface for the parts from which component's appearence is built: qucs::Line, qucs::Arc, qucs::Rect, qucs::Ellips, qucs::Text. With this commit they a turned from "dumb" POD to more "smart" objects. Common interface also allows to hide drawing logic and make drawing more convenient and easy for client code.
Here is a log portion with the error message from MacOS build. Unfortunately I am not able to debug this. I have no acces to Mac hardware and Clang fails on the CMake step using my host Linux machine.
|
I have tested this PR and found a bug. The net names are shown after every simulation. Press F2 and you will see something similar to the attached screenshot. The DC bias mode F8 works as expected. Other schematic editing features work as expected. I am considering to merge this after fixing the bug with net names display. |
@ra3xdh I think the last commit should fix this (I accidentally lost the |
You may use the following schematic to test parameter sweep: |
@ra3xdh that was hard, but I believe I've grasped the logic (I left the comment) and the fix will help! I've tested it with the provided schematic and it worked perfect. By the way is there an option to do something like |
Yes, the plots are rendered correctly now.
I think, it's better to keep the history as is. |
@ra3xdh yes, this is expected. I am going to prepare a PR with adjustments to individual components like this one, or resistor, 4bit pattern, etc. All components having texts as part of their symbol are affected in some way, because font size in "Points" font size has different size in pixels on different mediums, for example 12 points may be 120 pixels on one screen, 96 on another and 1600 pixels on a printer, but a 10x50 pixels rectangle is 10x50 pixels everywhere. |
I do hope I haven't confused or missed something, it would be great to see how it renders on screens with different PPIs. If everything is right then there should be no difference in relative sizes of component symbol's lines, circles, etc. and texts on any device. |
Thanks for the contribution! Merged. The schematic rendering is improved with this PR. |
Hi!
This is a major refactoring of Qucs-S drawing subsystem. There are a lot of changes, both visible by for the end user and internal.
Visible changes:
This gives natural and beautiful schematic appearance, especially when you're actually zooming in or out. Here some examples to compare between 24.1 and this patched version:
Export to image 24.1:
![X2_100_Bipolar-export-scale-0 5_Qucs-S-24 1](https://private-user-images.githubusercontent.com/40355531/331834215-897ff660-2f8b-464e-9b08-6892d0508f89.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2MDExNjAsIm5iZiI6MTczOTYwMDg2MCwicGF0aCI6Ii80MDM1NTUzMS8zMzE4MzQyMTUtODk3ZmY2NjAtMmY4Yi00NjRlLTliMDgtNjg5MmQwNTA4Zjg5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjE1VDA2Mjc0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTEyMGFhN2UxMDBjNDJmY2MzNWE4ODVkNzU5ZWUyNTNjNTNiYmY1MmNiNTBiNmZiYWU2ODgwNzg5YjNjZDdiYWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.jPz6MkF1NMCfI3Hpq4YwtG4XgopMyQ4HTv8-EEcfFNw)
Export to image patched:
![X2_100_Bipolar-export-scale-0 5_Qucs-S-patched](https://private-user-images.githubusercontent.com/40355531/331834217-615ce5b1-2dfb-42fa-8bfc-5e0979716db8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2MDExNjAsIm5iZiI6MTczOTYwMDg2MCwicGF0aCI6Ii80MDM1NTUzMS8zMzE4MzQyMTctNjE1Y2U1YjEtMmRmYi00MmZhLThiZmMtNWUwOTc5NzE2ZGI4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjE1VDA2Mjc0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWZlMWE3ZGM3NmVmNjIzODYwNzdlODJkZDYzYjE4ZDA0Njg5OTlmY2Y3NDk3OWViOTQ4MTkxM2I3NDVlN2Q5ZTUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.p_gh5me4MARUSAhvsua_sdmFNSsLNxI2Z8Rkmm2K3bM)
Print to file fitting to page:
X2_100_Bipolar-print-fit-to-page_Qucs-S-24.1.pdf
X2_100_Bipolar-print-fit-to-page_Qucs-S-patched.pdf
Zooming:
zooming-Qucs-S-24.1.webm
zooming-Qucs-S-patched.webm
Components don't turn into lumps when view is zoomed out, texts don't "shiver". And the same goes for printing and exporting. Schematic looks the same when exported or printed: natural scaling with no lumps
The most significant internal change is migrating all drawing from
ViewPainter
to a bareQPainter
and relying heavily on its facilities likesave()/restore()
and transformations. This makesViewPainter
obsolete and it's deleted.There are several reasons for this change, in short: ViewPainter is a hand-crafted analogue of QPainter+QTranform and it does its work bad. For example
p->DX + float(cx + pt->x) * p->Scale
which are quite cryptic to be honestand texts likes this:
or this:
— notice how wordy it is, notice the direct access to QPainter and repeating cryptic computations.
At the same time QPainter and QTransform are tested and provide convinient API for scaling, translating, etc. which hides all the gory details; QPainter and QTransform come from a lib used by a lot of people and one can search for help online, etc.
PR organization
There are a lot of changes in a lot of commits. I know it's against all the rules, but unfortunately there was no way to migrate gradually. And it didn't make sense also: having parts of the schematic drawn in different ways resulted in just ugly picture.
I made commits atomic and none of them breaks the app, you can checkout on any of them and the app would compile.
The general structure is the following:
paint
function are added, laying the foundation, and when everything is ready theSchematic
class is switched to a new drawing subsystem.Component::paintIcon
is migrated to a QPainter in a single commit