我希望这个问题不会被认为太笼统。我知道要在JPanel上绘制图形，需要重写paintComponent方法并将所有绘图代码放在该方法中。我的问题是为什么！为什么Java似乎不允许/提供使用诸如panel.drawLine(x1,y1,x2,y2)或panel.drawText(text,x,y)等方法进行绘图？在Delphi中这一切都容易多了。肯定有原因，只是我想不出来。
为什么在Java中绘制图形要使用paintComponent方法？
4
- Tony Wolff
1个回答
10
那是因为这是它的工作方式。它是以这种方式设计的。但我想你的问题是关于“为什么”的。
记住，Swing 几乎是 15 年前首次推出的。其中一个批评是 API 很慢（事实上，它之所以慢是因为人们没有真正理解如何使用它，但那是另一回事），所以必须在设计 API 时考虑性能。
涉及多个因素...
Swing 使用被动绘制过程，这意味着绘制请求是针对绘制子系统进行的，并被安排（回到 EDT）进行处理。绘制子系统会决定应该绘制什么、何时以及绘制多少。这由绘制子系统决定。
这意味着您永远不知道何时可能执行绘图周期，因此我们需要一种方法来能够响应这些请求。
灵活性是另一个因素。API 足够抽象，这并不重要，组件正在绘制到哪里。也就是说，您可以将其绘制到屏幕、打印机甚至是图像上。这意味着您不必重复大量的绘图代码，即可使其在不同设备上工作。
您永远不知道组件何时会变得可显示（也就是说，当它附加到本机对等体时）。这意味着图形上下文可能为 null，因此具有“帮助器”方法可能会导致更多问题。在调用 paintComponent 时，您（大部分情况下）保证有一个有效的图形上下文来绘制。
扩展性将是另一个因素。不仅可以很容易地覆盖 paintComponent 来改变某些组件的绘制方式，而且绘图系统还可以提供扩展的 Graphics 上下文，就像当前的情况一样。当调用 paintComponent（至少由绘制子系统调用）时，它保证 Graphics 上下文将是 Graphics2D 的一个实例，它是 Graphics 的扩展，为 API 提供了许多重要的增强功能。
记住，Swing 几乎是 15 年前首次推出的。其中一个批评是 API 很慢（事实上，它之所以慢是因为人们没有真正理解如何使用它，但那是另一回事），所以必须在设计 API 时考虑性能。
涉及多个因素...
Swing 使用被动绘制过程，这意味着绘制请求是针对绘制子系统进行的，并被安排（回到 EDT）进行处理。绘制子系统会决定应该绘制什么、何时以及绘制多少。这由绘制子系统决定。
这意味着您永远不知道何时可能执行绘图周期，因此我们需要一种方法来能够响应这些请求。
灵活性是另一个因素。API 足够抽象，这并不重要，组件正在绘制到哪里。也就是说，您可以将其绘制到屏幕、打印机甚至是图像上。这意味着您不必重复大量的绘图代码，即可使其在不同设备上工作。
您永远不知道组件何时会变得可显示（也就是说，当它附加到本机对等体时）。这意味着图形上下文可能为 null，因此具有“帮助器”方法可能会导致更多问题。在调用 paintComponent 时，您（大部分情况下）保证有一个有效的图形上下文来绘制。
扩展性将是另一个因素。不仅可以很容易地覆盖 paintComponent 来改变某些组件的绘制方式，而且绘图系统还可以提供扩展的 Graphics 上下文，就像当前的情况一样。当调用 paintComponent（至少由绘制子系统调用）时，它保证 Graphics 上下文将是 Graphics2D 的一个实例，它是 Graphics 的扩展，为 API 提供了许多重要的增强功能。
这一切都可以在不需要更改人们正在使用的基类的情况下完成，因此如果他们不想使用这些功能，它们不会受到影响。
你可能想要阅读以下资料...
有关更多详细信息
并且请记住“绘画很有趣” ;)
其他想法
其中考虑之一是，Graphics API 对于绘画非常重要，不仅与UI有关，还涉及打印和图像处理。该API与其目标断开联系，从而具有更大的灵活性但也具有共通性。
这意味着，如果您需要打印到打印机或渲染到图像，则可以使用用于屏幕绘画的相同API。
- MadProgrammer
1
啊，我现在应该删除我的回答。好的回答，点赞+1。 - Eng.Fouad
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接