Changeset View
Standalone View
plugins/scenes/opengl/scene_opengl.cpp
Show First 20 Lines • Show All 1168 Lines • ▼ Show 20 Line(s) | 1130 | { | |||
---|---|---|---|---|---|
1169 | } | 1169 | } | ||
1170 | 1170 | | |||
1171 | // Update the texture filter | 1171 | // Update the texture filter | ||
1172 | if (waylandServer()) { | 1172 | if (waylandServer()) { | ||
1173 | filter = ImageFilterGood; | 1173 | filter = ImageFilterGood; | ||
1174 | s_frameTexture->setFilter(GL_LINEAR); | 1174 | s_frameTexture->setFilter(GL_LINEAR); | ||
1175 | } else { | 1175 | } else { | ||
1176 | if (options->glSmoothScale() != 0 && | 1176 | if (options->glSmoothScale() != 0 && | ||
1177 | (mask & (PAINT_WINDOW_TRANSFORMED | PAINT_SCREEN_TRANSFORMED))) | 1177 | (mask & (PAINT_WINDOW_TRANSFORMED | PAINT_SCREEN_TRANSFORMED))) | ||
davidedmundson: This needs some work, but I understand what you're doing.
Logically we should have some sort… | |||||
Good that you mention it. I forgot to talk about it in the description. Indeed this stuff was one of the worse problems and I don't yet fully understand it. Without these changes including the generateMipmaps call the XWayland texture of a HiDPI client looked blurry on the LoDPI display. This makes in some way sense since mip-maps are used for down-scaling. But why do we not have the same problem with Wayland native buffers of larger scale factor and parts of them being shown on LoDPI screens? There everything looks crisp although it also needs to be downscaled. Maybe does the glViewport call in our EGl GBM backend do this automatically? But if yes, why not for the XWayland buffers. They should behave in this aspect exactly the same. romangg: Good that you mention it. I forgot to talk about it in the description.
Indeed this stuff was… | |||||
1178 | filter = ImageFilterGood; | 1178 | filter = ImageFilterGood; | ||
1179 | else | 1179 | else | ||
1180 | filter = ImageFilterFast; | 1180 | filter = ImageFilterFast; | ||
1181 | | ||||
1182 | s_frameTexture->setFilter(filter == ImageFilterGood ? GL_LINEAR : GL_NEAREST); | 1181 | s_frameTexture->setFilter(filter == ImageFilterGood ? GL_LINEAR : GL_NEAREST); | ||
1183 | } | 1182 | } | ||
1184 | 1183 | | |||
1185 | const GLVertexAttrib attribs[] = { | 1184 | const GLVertexAttrib attribs[] = { | ||
1186 | { VA_Position, 2, GL_FLOAT, offsetof(GLVertex2D, position) }, | 1185 | { VA_Position, 2, GL_FLOAT, offsetof(GLVertex2D, position) }, | ||
1187 | { VA_TexCoord, 2, GL_FLOAT, offsetof(GLVertex2D, texcoord) }, | 1186 | { VA_TexCoord, 2, GL_FLOAT, offsetof(GLVertex2D, texcoord) }, | ||
1188 | }; | 1187 | }; | ||
1189 | 1188 | | |||
▲ Show 20 Lines • Show All 297 Lines • ▼ Show 20 Line(s) | 1473 | for (int i = 0; i < LeafCount; i++) { | |||
1487 | nodes[i].texture->setWrapMode(GL_CLAMP_TO_EDGE); | 1486 | nodes[i].texture->setWrapMode(GL_CLAMP_TO_EDGE); | ||
1488 | nodes[i].texture->bind(); | 1487 | nodes[i].texture->bind(); | ||
1489 | 1488 | | |||
1490 | vbo->draw(region, primitiveType, nodes[i].firstVertex, nodes[i].vertexCount, m_hardwareClipping); | 1489 | vbo->draw(region, primitiveType, nodes[i].firstVertex, nodes[i].vertexCount, m_hardwareClipping); | ||
1491 | } | 1490 | } | ||
1492 | 1491 | | |||
1493 | vbo->unbindArrays(); | 1492 | vbo->unbindArrays(); | ||
1494 | 1493 | | |||
1495 | // render sub-surfaces | 1494 | // render sub-surfaces | ||
1496 | auto wp = windowPixmap<OpenGLWindowPixmap>(); | 1495 | auto wp = windowPixmap<OpenGLWindowPixmap>(); | ||
1497 | const auto &children = wp ? wp->children() : QVector<WindowPixmap*>(); | 1496 | const auto &children = wp ? wp->children() : QVector<WindowPixmap*>(); | ||
I think GL_LINEAR shouldn't be used in this case. Why mipmaps anyway? I don't see where the number of levels is set. zzag: I think GL_LINEAR shouldn't be used in this case. Why mipmaps anyway? I don't see where the… | |||||
From my research the number of levels is not something to be set, but it's determined by the size of the texture to be mip-mapped. A 2x2 texture has 2 mip-maps (2x2, 1x1), a 4x4 texture has 3 (4x4, 2x2, 1x1). Don't know why our code tries to set levels. romangg: From my research the number of levels is not something to be set, but it's determined by the… | |||||
1498 | windowMatrix.translate(toplevel->clientPos().x(), toplevel->clientPos().y()); | 1497 | windowMatrix.translate(toplevel->clientPos().x(), toplevel->clientPos().y()); | ||
1499 | for (auto pixmap : children) { | 1498 | for (auto pixmap : children) { | ||
1500 | if (pixmap->subSurface().isNull() || pixmap->subSurface()->surface().isNull() || !pixmap->subSurface()->surface()->isMapped()) { | 1499 | if (pixmap->subSurface().isNull() || pixmap->subSurface()->surface().isNull() || !pixmap->subSurface()->surface()->isMapped()) { | ||
1501 | continue; | 1500 | continue; | ||
1502 | } | 1501 | } | ||
1503 | renderSubSurface(shader, modelViewProjection, windowMatrix, static_cast<OpenGLWindowPixmap*>(pixmap), region, m_hardwareClipping); | 1502 | renderSubSurface(shader, modelViewProjection, windowMatrix, static_cast<OpenGLWindowPixmap*>(pixmap), region, m_hardwareClipping); | ||
1504 | } | 1503 | } | ||
1505 | 1504 | | |||
▲ Show 20 Lines • Show All 1108 Lines • Show Last 20 Lines |
This needs some work, but I understand what you're doing.
Logically we should have some sort of:
if (bufferSize != windowLogicalSize * outputScale) {
}
Though I remember trying it and couldn't see a difference.
We can split that out this patch and ship that.