Screenshots: documentation, pull requests

[Vladimir Sitnikov <si...@gmail.com>]

Hi,

JMeter heavily relies on the UI, and would probably be nice if we could
have machinery for automated screenshot generation.

I see the following issues with the current screenshots:
1) They are often out of date
2) Image quality is not always good (e.g. LowDPI image does not work for
HiDPI screen)
3) Image themes are not consistent. One screenshot can be dark, another can
be light, and so on :(

What do you think if we replace screenshots with automatically generated
ones?

I've created a draft PR: https://github.com/apache/jmeter/pull/574
I implement a small class that instantiates GUI components and generates
PNG files out of it.

So far my findings are:
a) The full set of screenshots takes ~7 megabytes (or ~3.5 after pngquant).
We would probably want to keep screenshots in another repository.
Otherwise, we could pollute the main source repository with images quite
fast.
b) Different operating systems have slightly different rendering because
the default fonts are different
c) If we use a different repository for storing screenshots, then we could
render even multiple themes and add "preferred theme" switch to the website
d) A single component might need more than one screenshot (e.g. HTTP
request have multiple tabs)


Any thoughts?

Vladimir

Re: Screenshots: documentation, pull requests

[Vladimir Sitnikov <si...@gmail.com>]

>Is there somewhere we can host them, like netlify or S3, instead of git?

Well, we can try Netlify, however, I'm not sure we are OK within their
limits.
A year ago I've raised https://issues.apache.org/jira/browse/INFRA-18102 for
use of Netlify for documentation preview, and the infra response was not
that positive.

Now I see they enable GitHub-Netlify integration for some of the projects.

Do you think you could explore the ways to preview the results?

So far I see the following key outputs:
* Documentation (e.g. canned screenshots for use in the online
documentation)
* UI regression testing: the system should render new screenshots, compare
them (with tolerance) with the etalon ones
(e.g. with the current screenshots), and produce the list of the ones that
differ significantly.

>What about the custom highlights around specific parts of the screenshot

It would be nice to have as well as
* custom values for fields
* custom size for the control
* crop

Frankly speaking, I think behind the lines of Kotlin DSL for that.

>instead of git

We might want to have documentation for **all** JMeter versions on the
website at the same time.
In other words, it would be great to have a version selector, so the users
could check the documentation for their version.

That implies we might want to store screenshots for all the versions rather
than "the latest screenshot for ThreadGroupGui".

Vladimir

Re: Screenshots: documentation, pull requests

[Graham Russell <gr...@ham1.co.uk>]

Great idea. There is a lot of room for improvement here.

Is there somewhere we can host them, like netlify or S3, instead of git?

What about the custom highlights around specific parts of the screenshot,
is that easy to automate too, but maybe not essential?

Graham

On Wed, 25 Mar 2020, 21:42 Vladimir Sitnikov, <si...@gmail.com>
wrote:

> Hi,
>
> JMeter heavily relies on the UI, and would probably be nice if we could
> have machinery for automated screenshot generation.
>
> I see the following issues with the current screenshots:
> 1) They are often out of date
> 2) Image quality is not always good (e.g. LowDPI image does not work for
> HiDPI screen)
> 3) Image themes are not consistent. One screenshot can be dark, another can
> be light, and so on :(
>
> What do you think if we replace screenshots with automatically generated
> ones?


> I've created a draft PR: https://github.com/apache/jmeter/pull/574
> I implement a small class that instantiates GUI components and generates
> PNG files out of it.
>
> So far my findings are:
> a) The full set of screenshots takes ~7 megabytes (or ~3.5 after pngquant).
> We would probably want to keep screenshots in another repository.
> Otherwise, we could pollute the main source repository with images quite
> fast.
> b) Different operating systems have slightly different rendering because
> the default fonts are different
> c) If we use a different repository for storing screenshots, then we could
> render even multiple themes and add "preferred theme" switch to the website
> d) A single component might need more than one screenshot (e.g. HTTP
> request have multiple tabs)
>
>
> Any thoughts?
>
> Vladimir
>