You understand what a component is?
Now in heavyweight each component has its own canvas to draw on,
in lightweight there is just one canvas ( native screen resource)
(that of java.awt.Window i think) and all the component are painted
by a paintComponents method ( dont know the name exactly),

the paintComponenets will correctly call the paintComponent(Graphics
g) of each component.

understand it?

A "native screen resource" is a generic term that the page you're
reading uses for some platform-specific representation of a GUI
widget/component/control/whatever from the operating system where the
application is running.

Traditionally, operating systems (or windowing systems) provide some
kind of a concept of a GUI "component" or "widget" or "control", all of
which mean approximately the same thing.  If I build a typical Windows
application, the operating system kernel knows about each individual
check box or other widget on each of my windows.  In other cases, it may
just be a separate process (such as an X Windows server) that knows
about each widget... or even just a user-space library.  In any case,
something written in native code is aware of that widget.

The term "peer" is AWT-specific.  It refers to the fact that each widget
is represented by an object in Java, and ALSO by some data structure or
object in the native platform.  The Java object is called the component,
from AWT's perspective, and the native data structure or object is
called the "peer".

Basically, a heavyweight component has a peer, meaning that it is
implemented with the full consent, knowledge, and cooperation of the
operating system or windowing system.  A lightweight component lacks a
peer, which means that the operating system (whether kernel, or separate
process, or user-space library, or whatever) does NOT know about that
object.  Instead, the Java virtual machine creates the parent, and keeps
to itself that there is a check box in a certain location.

See http://mindprod.com/jgloss/peer.html