The solution differs between the two of them; QML is likely the easier one, as there is a global environment variable we could try and set that would automatically scale everything within the same process.
These are three you could try on your end and see if they make a difference for QML.
If so, it would be trivial to add this to the
from PyQt5 import QtCore from PyQt5.QtWidgets import QApplication os.environ["QT_AUTO_SCREEN_SCALE_FACTOR"] = "1" app = QApplication(sys.argv) app.setAttribute(QtCore.Qt.AA_EnableHighDpiScaling)
pyblish_qml/ipc/server.pyfor what variables are added, and maybe try adding it there instead.
Not quite, I was thinking.
context.create("myInstance")and gather nodes for that instance, if there are any
Alternatively, you could make a validator that checks the context. If it's empty, throw an error.
import pyblish.api class ValidateContextHasInstance(pyblish.api.ContextPlugin): order = pyblish.api.ValidatorOrder - 0.49 # First validator def process(self, context): msg = "No instance to publish, please create at least one instance." assert len(context), msg msg = "No instance to publish, please enable at least one instance." assert any(inst.data.get("publish", True) for inst in context), msg
class ValidateCollectionProcesses(pyblish.api.ContextPlugin): """Validate previous collector plugins all processed without error """ order = pyblish.api.ValidatorOrder - 0.49999 def process(self, context): assert all(result["success"] for result in context.data["results"]), ( "Collected with error, there must be bugs.")
Main issue is that each application does not draw only pyblish-gui but also it's gui and also have to care about it's threads.
Standalone pyblish gui works faster all the time, but is unusable for publishing because you need access to application memory during publishing, if you want access to application memory you have to run it inside application.
*Or you can find way how to access application memory in other way (e.g. with sockets, websockets or something similar).
Blender is much complicated BTW. Blender does not use Qt so you have to create new Qt application on top of blender's application.
If you need to have GUI for publishing you can't have same speed as standalone, you can only increase perforance of your GUI with reducing unnecesary parts.
*It seems that each item in your list view has 5 parts to paint: checkbox, icon, label, author and ?frames? each item has many rounded rectangles, different states and different backgrounds. That's what I can see from the prinscreen you've sent.
paintEventdirectly, but instead render to a
QPixmaponly when necessary, and draw it with a
QLabel. That way, the
paintEventof the QLabel will merely draw pre-rendered pixels, which is fast, and you can delegate the heavy rendering to when you actually need it. Otherwise, the
paintEventis called tens of thousands of times for all sorts of silly reasons.
flowpipeindeed is something that can be put together !
publish2, and I've captured some of their ideas here: https://forums.pyblish.com/t/pyblish-and-shotguns-publish2/607