@vv Thank you.

@Carl Love You wrote, "My opinion is that all algebraic equations eq given as input to any Maple program should be preprocessed with (lhs-rhs)(eq)."

As a blanket suggestion even just for user programming, and despite the fact that it might be useful in the context of Rouben's approach to this problem, that doesn't sound like a very good idea.

There are many cases in which an algebraic equation is sensibly and usefully used to represent a substitution/evaluation rule or an identity/equivalence/lookup. The lhs-rhs action would remove that wanted information.

@Kitonum The order of results from RealDomain:-solve is not guaranteed here, so extracting the y-values from Sol individually by position is problematic.

In Maple 2020.1 I get the reverse order using that code, which makes the final Area result negative, ie. an incorrect answer.

simplify(fnormal(int(g[1]-f[1], y=op([2,2],Sol[2])..op([2,2],Sol[1]))),zero);

            -0.75833670466253534952

As I realize that you know, there are lots of ways to extract the min and max values, eg. one possible fix-up is:

ymin,ymax := [min,max](map[2](eval,y,[Sol]))[];
simplify(fnormal(int(g[1]-f[1], y=ymin..ymax)), zero);

@mmcdara You can submit a Software Change Request directly from this forum by using the forms on its SCR page. (The format is more like a Bug Report, but whoever reads it will likely understand if you phrase it as a Feature Request, aka Request For Enhancement.)

I don't quite understand why not to mention up front in the Mapleprimes Question if you need a solution specifically in terms of the Maplets Plotter.

@Joel19 You can add this option, after a comma, into the end of the plot(...) call.

     labels=[b, ""]

where "" is the empty string (ie. two doublequotes).

How should it handle abs(1,x) ?

@Bland3 I don't understand precisely why you are trying to write your own procedures for mimicing axes and tickmarks and tickmark labels.

It would help if you could state clearly what aspect of those things is not supported by the plot,axis and plot,tickmarks options. Specific examples and detailed descriptions of what you have not been able to accomplish using those would be helpful.

There are (of course) some aspects of functionality that are not provided by the current plotting options. But your attached worksheet(s) don't make it clear and explicit which if any of those you are trying to add and provide.

Given how the significant effort it would be to reproduce properly even the existing functionality I think that it would be prudent to first ensure that the functionalities you want are not currently achievable.

For example, the following things can be achieved with the current functionality, although it requires some creativity to come up with the solutions -- the documentation examples are skimpy.
  - all tickmark labels in common representation (scientific/engineering/reflated float format)
  - forced tickmark labels mixed with forced tickmark positions (ie. some in common location, some blank labels at some tickmarks, etc)
  - common font size and color for each axis's tickmark labels (but different per axis)
  - different font size and color for some tickmark labels along a common axis
etc.

Could you provide specific examples for most of the pieces of functionality for plotting axes which you have not been able to achieve?

There may be little point is getting it to run, at present, since the current performance of the Intel MKL BLAS gemm and gemv are so good.

The small number of CUDA enabled LinearAlgebra functions (Matrix-Matrix multiply and Matrix-Vector multiply) are so fast that the transfer time to upload/download the data to/from the GPU obscures the computation time.

Having said that, I see a few ideas for the future (although I think I wrote something similar a few years ago...).

1) Get one of the fuller LAPACK compilations (in GPU, of course) to work. The last time I checked there were a couple of candidates. But at that time neither had yet finished doing or optimizing the svd and nonsymmetric eigen-solvers, which have the higher complexity algorithms and longer computation times so that transfer-every-time wouldn't hide the benefits.

2) Make new "foreign DAG" MatrixVector in Maple whose hardware data lives on the card. (And procs to push up, and pull down, such beasts.) Then compound linear-algebra operations could be done on those, with the transfer overhead seen only at front and end of the computation.

3) Write BLAS and LAPACK direct front end packages in Maple. Have these access MKL or CUDA, as chosen. Bonus points for CodeGeneration or Compiler:-Compile of procs that use these.

These are all interesting, but it's unclear that the benefit would be in high enough demand. It might be tricky to justify these over, say, a new fast hardware quad-precision BLAS/LAPACK.

@chrisc Does it improve if you close the left panel (the "palette" pane)?

How about the right panel (the content-menus)?

Do you perhaps mean the Standard Java GUI?

@Carl Love 

You wrote, "It is obvious that the proper evaluation of F(G(e1, e2)) assuming a1, a2 requires that the assumptions be applied before F(G(e1, e2)) is evaluated."  But that aspect that you describe as obvious seems to be crux of what surprised the OP -- ie. the fact that all instances of name `x` within the unevaluated expression are temporarily replaced with an assumed name, prior to any part of F(G(e1,e2)) being evaluated. Hence the replacement with assumed names happens before even G(e1,e2) is computed.

That is the ususal evaluation model of `assuming`. It is (IMO) conveyed by the first sentence in the Desciption of the Help page for that command. The entirety of the first argument is evaluated under the assumptions placed on the names present.

@Kitonum Yes, but regardless of the strength of `solve`, isn't it zero over that wider domain?

I don't see why examination of the domains of subexpressions (radicals, csgn, ln, etc) present in some *particular* representation should always be an adequate and correct methodology. Their individual imaginary contributions may cancel for some x. Just because we don't know how to simplify/manipulate the expression into a representation where it clarifies differently doesnt mean that the expression might not be real-valued on a larger domain.

@Kitonum Why should one care that some arbitrary part of the expression may be considered as nonreal, as long as the whole expression is zero?

@Kitonum Perhaps I am missing something.

Why not   -exp(2)-1<x, x<=exp(2)-1  ?

(I don't mean just what solve returns.)

@snowman I just threw that in so that the procedure FF would return unevaluated if called with an argument that was not a number (eg. a name). That allows you to pass around FF(r), with r an unassigned name. It is not necessary here since the procedure returned by Interpolate (and assigned to F) already behaves like that. But when I started writing I didn't know for sure that I'd stick with the Interpolate approach.

The same mostly goes for that try...catch. I didn't know whether I'd need it, and I was suppressing potential difficulties.

Here is a copy of that worksheet which uses just F, and omits FF as wrapper. It works as well.
   polar_densityplot_modif.mw

Btw, I notice a slightly more even color gradient (visually more even, to my eye, at least) if I make the colorscheme progress through the Luv color space rather than the default. Another possibility is to adjust the grid resolution. Your opinion might differ. Eg,

plots:-densityplot(F(r), r=0..1, theta=0..2*Pi,
                   style=surface, axiscoordinates=polar,
                   labels=["", ""], grid=[101,51],
                   colorscheme=["zgradient",["White","Red"],
                                colorspace="Luv"]);